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Abstract _ _ _ _ 

This  document  is  the  fourth  in  a  series  of  reports  documenting  the  structured  design  process 
of  Buylt.  As  part  of  the  Corporate  Business  Application  Software  System  (C-BASS)  suite  of 
work  flow  and  information  management  softw  are,  Buylt  automates  small  purchase  orders  for  the 
U.S.  Army  Research  Laboratory  (ARL).  The  software  testing  plan  developed  in  this  document 
was  derived  from  two  antecedent  documents:  “Buylt  Software  Requirement  Analysis  and 
“Buylt  Detailed  Design  Report.”  The  testing  plan  for  Buylt  is  delineated  in  the  five  major 
sections  of  this  report  (1)  “Usability  Testing,”  (2)  “Preparing  for  Usability  Testing,”  (3)  “Alpha 
Testing,”  (4)  “Beta  Testing,”  and  (5)  “User  Testing  Plan  Task  List”  Together,  they  describe  an 
overall  strategy  for  testing  as  well  as  delineate  the  test  cases  to  be  used  to  demonstrate  that  the 
software  works  according  to  its  specifications. 
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1.  Introduction 


Buylt  is  a  component  of  the  Corporate  Business  Application  Software  System  (C-BASS) 
family  of  applications,  an  integrated  set  of  Lotus  Notes  and  Web-based  software  to  support 
U.S.Army  Research  Laboratory  (ARL)  electronic  workflow  and  task  automation.  The 
motivating  force  behind  this  project  has  been  ARL  downsizing  and  the  findings  put  forth  in  the 
Business  Process  Reengineering  (BPR)  report  on  the  small  purchase  process  [1]. 

The  purpose  of  the  Buylt  prototype  is  to  model  a  secure  client/server  system  that  provides  for 
the  processing  of  small  purchase  requests.  This  proof-of-principle  prototype  will  alleviate  some 
of  the  risks  involved  in  implementing  new  technologies  used  to  build  the  ARL  Intranet.  The 
project  will  also  refine  requirements  described  in  the  ARL  Business  Process  Reengineering 
(BPR)  “To-Be  Model”  [1]. 

1.1  The  Buylt  Software  Documentation  Library.  This  report  is  the  fourth  in  a  series 
documenting  the  various  phases  of  the  development  of  the  software  system  Buylt  Prototype. 
Buylt,  once  implemented,  will  provide  ARL  with  a  secure,  automated,  and  networked  software 
system  for  preparing,  routing,  approving,  tracking,  and  reporting  the  procurement  of  small 
purchases. 

In  keeping  with  the  conventions  of  modem  software  engineering,  Buylt’ s  design  has  been 
carefully  documented.  Three  documents  precede  tiiis  software  test  plan: 

(1)  “Buylt  Software  Development  Plan”  [2]  -  defines  the  problem;  gives  an  overview  of 
technical,  management,  and  reliability  issues;  and  provides  a  detailed  project  schedule, 
including  milestones. 

(2)  “Buylt  Software  Requirements  Analysis”  [3]  -  reports  on  the  work  accomplished  to 
solidify  user  requirements  and  the  analytical  expansions  used  to  derive  a  data  flow 
model,  a  pseudocode  representation  of  processing,  and  a  data  dictionary. 
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(3)  “Buylt  Detailed  Design  Report”  [4]  -  finalizes  the  design  of  all  data  structures  internal 
to  each  component  and  provides  a  representation  of  program  logic  at  a  relatively  low 
level  of  abstraction  using  the  formalisms  of  structure  charts  and  module  specifications. 

1.2  Contents  of  This  Document.  Buylt  is  currently  designed  as  a  prototype  system  to  be 
implemented  at  the  Adelphi  Laboratory  Center  (ALC)  in  a  Windows  environment.  The  scope  of 
the  prototype  is  limited  such  that  all  workflow  contingencies  are  not  included  at  this  time. 
Pending  prototype  approval,  future  enhancements  will  cover  the  full  scope  of  the  workflow 
process. 

Using  modem  software  engineering,  testing  is  no  longer  a  late-phase,  random,  or  ad  hoc 
event  in  the  development  process.  Rather,  the  design  characteristics  of  the  software  are  used  as  a 
foundation  for  concurrently  developing  a  coherent  test  plan.  This  report  contains  five  major 
sections:  (1)  “Usability  Testing,”  (2)  “Preparing  for  Usability  Testing,”  (3)  “Alpha  Testing,” 
(4)  “Beta  Testing,”  and  (5)  “User  Testing  Plan  Task  List”  Together,  they  describe  an  overall 
strategy  for  testing  and  delineate  the  test  cases  to  be  used  to  demonstrate  that  the  software  works 
according  to  its  specifications. 

2.  Usability  Testing 

The  purpose  of  the  Buylt  prototype  software  application  testing  plan  is  to  create  an  approach 
to  systematically  uncover  different  classes  of  errors  in  a  minimum  amount  of  time  with  a 
minimum  amount  of  effort,  thus  verifying  and  validating  that  all  Buylt  requirements  function  as 
stated  in  the  software  requirements  analysis  [3]. 

In  a  traditional  test  plan,  two  complementary  points  of  view  are  taken  in  order  to  develop  a 
complete  set  of  module  tests.  In  the  first,  the  modules  are  treated  as  “black  boxes.”  Test  cases 
consist  of  input  to  the  module,  and  evaluation  consists  of  comparison  of  the  ou^ut  with  expected 
results.  The  second  perspective — ^“white  boxes”— considers  the  internal  workings  of  the 
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modules.  From  this  perspective,  test  cases  are  derived  from  the  control  structure  of  the 
procedural  design. 

Because  Buylt  is  a  Lotus  Notes  application,  the  standard  testing  techniques  using  white  box 
testing  and  black  box  testing  are  adjusted.  Since  Lotus  Notes  applications  are  written  using 
formulas  and  LotusScript  and  are  not  stmctured  like  traditional  software  programs,  white  box 
testing  and  black  box  testing  are  combined  to  form  usability  testing  [5]. 

Usability  testing  attempts  to  find  errors  in  categories  such  as  (1)  incorrect  or  missing 
functions,  (2)  human-machine  or  interface  errors,  (3)  errors  in  data  structures  or  external  data 
base  access,  (4)  performance  errors,  and  (5)  initialization  and  termination  errors.  Thus,  in 
deriving  a  test  plan,  one  looks  first  at  the  information  domain  and  prescribed  system  tasks  of  the 
application. 

As  described  in  “Buylt  Software  Requirements  Analysis”  [3],  the  high-level  requirements  for 
the  prototype  system  to  be  tested  include  eight  elements: 

(1)  Security, 

(2)  Purchase  request  preparation, 

(3)  Automated  request  routing, 

(4)  Electronic  approval, 

(5)  Receive/accept  order, 

(6)  Request  tracking, 

(7)  Legacy  system  interface,  and 

(8)  Reporting. 

These  high-level  requirements  are  included  in  the  Buylt  workflow  and  lend  themselves  to  a 
scenario  form  of  testing.  As  described  in  “Buylt  Software  Requirements  Analysis”  [3],  workflow 
comprises  seven  major  business  processes  that  provide  an  orderly  approach  for  the  user  to  test 
the  functionality  of  Buylt: 
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(1)  Prepare  purchase  request, 

(2)  Approve  funds, 

(3)  Obtain  approvals, 

(4)  Edit  purchase  request, 

(5)  Prepare  purchase  order, 

(6)  Receive  shipment,  and 

(7)  Submit  inquiries. 


Usability  testing  for  Buylt  consists  of  two  parts:  alpha  and  beta  testing.  Alpha  testing  is 
done  by  the  developer  to  assure  that  the  overall  design  of  the  system  performs  as  expected.  Beta 
testing  (or  pilot  testing)  is  done  by  a  small  group  of  users  to  ascertain  tiiat  Buylt  functions  as 
intended  and  that  all  instructions  are  clear.  Additionally,  this  form  of  controlled  field-testing 
validates  that  Buylt  will  effectively  and  efficienti,y  follow  the  users’  cognitive  processes  in 
performing  smaU-purchase  functions. 


3.  Preparing  for  Usability  Testing 


The  following  is  a  checklist  designed  to  assist  the  software  developer  in  preparing  Buylt  for 
usability  testing. 

(1)  Compose  a  clear  list  of  tasks  for  the  testers  to  perform.  This  list  helps  the  developer 
isolate  key  functionality  areas  in  the  application  and  identify  ways  to  improve  tiiese  areas. 
Determine  flie  time  frame  for  the  testing,  the  number  of  testers  needed,  and  specify  the 
level  of  understanding  of  Lotus  Notes  and  the  Buylt  process  required. 

(2)  Adjust  the  Access  Control  List  (ACL)  to  include  the  testers  with  appropriate  access  and 
the  necessary  roles  adding  their  names  to  the  author  access  list. 

(3)  Test  Buylt  in  the  test  database.  Test  the  application  of  a  single  server.  Do  not  create 
replicas  at  this  stage. 
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(4)  Create  the  test  database  and  refresh  the  test  database  from  the  development  database. 
Save  a  copy  of  the  template  for  the  test  database  in  the  Buylt  system  repository. 

(5)  Test  Buylt  on  all  intended  platforms.  For  this  prototype,  the  intended  platform  is 
Windows. 

(6)  Create  the  Buylt  discussion  database  for  tester  feedback.  This  database  is  used  to  record 
errors  found.  Review  the  C-BASS  Standard  Configuration  Management  Plan  [6]  for 
more  details  on  creating  the  discussion  database. 

(7)  Consider  preventing  tihe  database  from  appearing  in  the  Open  Database  dialog  box.  This 
option  should  be  turned  off  before  Buylt  is  placed  into  full  production.  To  enable  testers 
to  access  Buylt,  send  them  a  mail  document  with  a  button  that  adds  Buylt  to  their 
workspace. 

4.  Alpha  Testing 

Modem  system  engineering  focuses  on  human-machine  interaction  as  much  as  it  does  on  the 
internal  transactions  of  code  modules.  Thus,  system  designers  must  test  for  such  ease-of-use 
attributes  as  user  help,  smooth  navigation,  and  coherent  information  display  [7-9].  To  assure 
consistency  of  the  user  interface,  Buylt  developers  should  perform  usability  tests,  ranning 
through  the  use  of  every  form,  subform,  view,  navigator,  and  agent  in  Buylt  The  following 
segments  detail  nine  system-specific  features  that  must  be  tested. 

4.1  Database  Help.  This  on-line  assistance  within  the  application  presents  straightforward 
directions  and  answers  questions,  making  it  easy  for  the  users  to  find  the  information  they  want 
and  to  navigate  through  the  application. 

Help  in  Buylt  is  located  in  two  areas:  (1)  the  Help  selection  from  the  menu  bar,  and  (2)  the 
histraction  button  in  the  action  bar. 
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The  Help  selection  from  the  menu  bar  contains  the  following  options:  “About  This 
Database,”  “Using  This  Database,”  and  “About  Lotus  Notes.”  The  developer  ensures  that  these 
options  operate  correctly  and  contain  accurate,  clear,  and  concise  information. 

The  Instruction  button  provides  designer/developer  and  user  information  on  “Using  the 
Approval  Cycle.”  Again,  the  developer  checks  these  documents  to  ascertain  that  the  information 
is  correct,  concise,  and  clearly  written.  Some  questions  the  developer  should  consider  when 
creating  the  online  help  are: 

( 1 )  Are  the  fields  and  buttons  clearly  labeled? 

(2)  Are  fields  on  the  form  arranged  in  a  way  that  makes  sense  to  the  user  and  laid  out  on 
the  form  to  facilitate  movement  through  the  form? 

(3)  Are  required  fields  and  important  information  highlighted  for  the  user? 

(4)  Is  it  cleM  where  to  start  in  an  application?  Is  it  clear  how  the  user  is  notified  of 
progress  in  workflow  applications  such  as  Buylt? 

(5)  Are  views  and  forms  clearly  named? 

(6)  Are  the  “About  Database”  and  “Using  Database”  forms  filled  out  and  edited  for  clarity? 

(7)  Are  all  window  titles  and  field  help  included  where  necessary? 

(8)  Have  declines  been  tested? 

(9)  Have  visual  cues  such  as  icons  and  color  been  exploited  in  a  helpful  but  nondistractmg 
way? 
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(10)  Are  a  name  and  a  phone  number  provided  in  the  event  a  user  must  contact  a  database 
manager? 

42  Policy  Documents.  These  are  built-in  documents  that  contain  information  that  identifies 
the  database  and  its  use.  Because  these  documents  are  also  found  in  “Database  Help,”  the 
procedures  for  checking  their  content  have  already  been  established.  At  this  point,  the  developer 
need  only  ensure  that  the  “About  This  Database”  appears  whenever  a  user  logs  onto  Buylt  for  the 
first  time. 

43  Database  Icons.  Database  icons  are  square  icons  that  represent  a  Lotus  Notes  database 
such  as  Buylt.  They  contain  pictures  and  descriptive  titles.  The  developer  checks  that  when  the 
Buylt  icon  is  double-clicked,  the  Buylt  system  appears. 

4.4  Form  Designs.  A  form  is  used  to  enter  and  to  view  data  contained  in  documents. 
Documents  are  composed  with  a  form  and  viewed  with  a  specific  form. 

The  developer  ascertains  that  aU  Window  titles  for  all  forms,  field  alignment,  field  formulas, 
computed  subforms  under  all  conditions,  author  and  read  access  lists,  authors  and  readers  fields, 
sections,  and  keyword  fields  are  correct  and  function  according  to  specifications. 

To  test  Buylt  forms,  the  developer  should: 

•  Select  View  >  Design. 

•  Select  Design  then  Forms  in  the  Navigation  pane.  A  list  of  all  Buylt  forms  appears. 

•  For  each  form,  double-click  to  open  it  and  then  choose  Design  >  Test  Form. 

•  Verify  that  each  form  meets  specifications. 

To  verify  that  each  form  meets  specifications,  the  developer  creates  two  or  three  documents 
and  then  uses  the  following  checklist. 
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(1)  Is  there  a  default  form  for  the  database?  If  not,  double-click  the  form  that  should  be  the 
default  and  choose  Design  >  Form  Properties.  Click  the  Defaults  tab  and  select  “Default 
database  form.” 

(2)  Do  all  forms  appear  correctly  on  the  Create  menu?  Are  the  appropriate  keyboard 
shortcuts  used?  Do  forms  appear  in  the  correct  order?  If  not,  check  the  names  and  the 
“Include  in  Menu”  selections  for  the  forms. 

(3)  Do  the  window  titles  for  each  of  the  forms  display  appropriately  under  different 
conditions?  If  not,  edit  the  window  title  formula.  To  display  the  window  title  when 
printing  a  form,  click  the  Printing  tab  in  the  Form  Properties  InfoBox  and  add  &W  to  the 
formula  for  the  header  or  footer. 

(4)  Check  cross-platform  compatibility,  if  applicable.  Are  all  fonts  used  in  this  form 
avjulable  or  approximated  on  all  platforms?  Does  all  text  display  legibly?  Are  platform- 
specific  terms  used  where  appropriate?  Keep  the  application’s  layout  as  generic  as 
possible  to  suit  aU  platforms. 

(5)  Are  related  fields  grouped  together  on  the  form?  If  not,  move  the  fields  and  their  related 
static  text  to  a  more  suitable  position. 

(6)  Do  forms  that  are  longer  than  one  page  have  page  numbers?  not,  click  the  Printing  tab 
in  the  Form  Properties  InfoBox  and  add  &P  to  the  formula  for  the  header  or  footer. 

(7)  Do  the  forms  include  Author  Names  fields  where  appropriate  for  tracking  document 
authors  and  editors?  If  not,  add  an  Author  names  field  to  the  form. 

(8)  If  needed,  has  a  “read  access  list”  been  defiuned  for  the  form?  This  is  defined  by 
assigning  names  to  a  Read  access  control  list  in  the  Form  Properties  InfoBox. 


8 


(9)  If  needed,  has  a  “create  access  list”  been  defined  for  the  form?  This  is  defined  by 
assigning  names  to  a  Compose  access  control  list  in  the  Form  Properties  InfoBox. 

4.5  Field  Designs.  The  developer  needs  to  review  the  fields  on  each  form  and  their 
formulas.  Fields  are  checked  for  the  following. 

(1)  Are  fields,  including  keywords,  showing  the  correct  information  when  first  displayed? 
hf  not,  check  the  default  value  formula. 

(2)  Does  every  editable  field  have  a  help  description?  If  not,  add  help  descriptions  for 
those  fields.  Sisure  that  field  descriptions  are  consistently  worded  and  that  ending 
punctuation  is  consistent  for  each. 

(3)  Can  users  enter  information  in  editable  fields?  If  not,  check  the  field  definition;  a 
Computed  option  could  have  been  wrongly  selected  when  defining  the  field. 

(4)  Are  editable  fields  formatted  correctly  once  the  document  is  saved?  If  not,  check  the 
input  translation  formula  and  the  format  for  the  field. 

(5)  Are  editable  fields  accepting  invalid  data  or  not  accepting  valid  data?  If  so,  check  the 
input  validation  formula. 

(6)  Are  computed  fields  computed  correctly?  Are  they  returning  values  of  the  appropriate 
data  type?  If  not,  check  the  field  formula  and  do  data  type  conversion  as  needed. 

(7)  Do  inherited  fields  inherit  their  data  correctly?  If  not,  check  the  field’s  default  value 
formula. 
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(8)  Do  required  fields  have  input  validation  formulas  that  display  an  appropriate  message 
when  the  user  tries  to  save  the  document  without  filling  in  the  fields?  If  not,  create  the 
input  validation  formulas  and  include  an  explanatory  message  for  the  user. 

(9)  In  time-date  fields,  is  the  time  displayed  correctly?  If  not,  ensure  that  the  appropriate 
time  zone  option  is  selected  from  the  field  format  dialog  box. 

(10)  Are  fields  aligned  properly  with  a  variety  of  window  sizes  and  on  different  monitors? 
If  not,  check  the  tab  settings  for  the  form. 

(11)  Are  encrypted  fields  accessible  to  those  with  the  encryption  key  and  inaccessible  to 
other  users?  If  not,  check  to  ensure  that  the  encryption  key  was  sent  to  all  the  right 
users.  If  users  who  should  not  have  access  to  encrypted  fields  do  have  access,  change 
the  encryption  key  and  resend  it. 

4.6  View  Designs.  A  view  is  a  tabular  display  of  all  or  of  a  subset  of  documents  in  a 
database.  For  each  view  in  Buylt  (e.g.,  the  Status  Inquiry,  Approval  Pending,  and  Reports),  the 
developer  ensures  that  column  justification,  column  formulas,  read  access,  selection  formulas, 
form  formulas,  view  layout  (hierarchical  view),  and  document  display  are  correct  and  function 
according  to  specifications.  Views  are  checked  for  the  following. 

(1)  Is  there  a  default  view  for  the  database?  If  not,  double-click  the  view  that  should  be  the 
default  and  choose  Design  >  View  Properties.  Click  the  Options  tab  and  select 
“Default  view  when  database  is  first  opened.” 

(2)  Is  there  a  View  by  Date?  If  not,  consider  adding  a  view  that  sorts  documents  by  date  so 
users  can  view  documents  in  chronological  order. 
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(3)  Do  all  views  appear  correctly  on  the  View  menu?  Are  the  appropriate  keyboard 
shortcuts  used?  Do  the  views  appear  in  the  correct  order?  If  not,  check  the  names  and 
the  “Show  in  View  Menu”  selection  in  the  View  Properties  MoBox. 

(4)  Is  the  information  in  the  view  easy  to  read?  If  it  appears  cluttered  or  if  the  colunms  are 
too  close  together,  reset  the  column  width  and  justification. 

(5)  Are  all  the  documents  that  should  be  in  the  view  displayed,  or  are  there  too  many 
displayed?  If  the  view  is  not  displaying  the  documents  intended,  check  the  view’s 
selection  formula. 

(6)  Are  die  response  documents  indented,  if  required?  If  not,  select  “Show  response 
documents  in  a  hierarchy”  on  the  Options  tab  of  the  View  Properties  InfoBox  and  create 
a  column  for  responses. 

(7)  Do  response  documents  correq)ond  to  the  correct  main  documents?  If  not,  check  the 
view’s  selection  formula;  ensure  that  the  responses-only  column  is  placed  directly  to  the 
left  of  the  colunm  that  displays  the  main  document  information. 

(8)  If  the  view  uses  categories,  are  the  categories  appearing  correctly?  If  not,  create  a 
sorted,  categorized  colunm  and  use  the  name  of  the  appropriate  keyword  field  as  its 
formula. 

(9)  If  there  are  form  formulas,  are  documents  selected  for  the  view  being  displayed  with  the 
correct  form?  If  not,  check  the  form  formula. 

(10)  Check  cross-platform  compatibility,  if  applicable.  Are  all  fonts  used  in  the  view 
available  or  approximated  on  all  platforms?  Are  column  widths  sufficient  for  all 
platforms?  Are  platform-specific  terms  used  where  appropriate?  Make  the 
application’s  layout  as  generic  as  possible  to  suit  all  platforms. 
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(1 1)  If  needed,  has  a  read  access  list  been  defined  for  the  view?  If  not,  create  it  by  selecting 
the  Security  tab  in  the  View  Properties  InfoBox. 

(12)  Is  the  information  in  each  column  correct?  If  not,  check  the  formulas  in  the  column 
definitions. 

(13)  Is  the  column  returning  values  of  the  appropriate  data  type?  If  not,  check  the  field 
formula;  columns  can  only  display  simple  text,  so  @Text  is  needed  in  the  formula  to 
display  values  from  numbers  or  time  fields. 

(14)  Is  each  column  displaying  all  the  information  that  is  contained  in  it?  If  not,  adjust  the 
column  width  and/or  the  font  used  for  displaying  the  colunm. 

(15)  Are  the  contents  of  the  columns  aligned  properly?  Numbers  should  be  right  justified; 
text  should  be  left  justified  or  centered.  Check  the  justification  for  each  column. 

(16)  Are  documents  in  the  right  order?  If  not,  check  that  the  columns  sorted  on  are  the 
correct  columns  and  that  the  correct  sorting  order  was  chosen. 

(17)  Are  the  documents  supposed  to  be  numbered?  If  so,  create  a  new  view  whose  first 
column  is  sorting  in  ascending  order  and  uses  @DocNumber  in  its  formula. 

4.7  Agents.  Agents  are  macros  that  are  designed  and  programmed  to  process  data  and 
perform  tasks  on  a  subset  of  documents  in  a  database.  If  the  agent  is  complex  or  calls  other 
agents,  the  developer  should  consider  segmenting  it  into  smaller  agents  to  test  different  tasks 
individually  before  combining  them. 

Currently,  there  are  no  agents  in  Buylt  Agents  will  be  developed  later  for  the  interfaces  to 
Standard  Operations  and  Maintenance  Army  Research  and  Development  System  (SOMARDS) 
and  to  the  Standard  Army  Automated  Contracting  System  (SAACONS).  The  following 
procedures  will  apply  once  Buylt  agents  are  written. 
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While  using  the  test  database,  the  developer  should  execute  each  agent  in  Test  and  in  Run. 
Test  mode  does  not  modify  the  document(s),  but  produces  a  report  on  how  the  agent  functions. 
Run  mode  modifies  the  test  document(s)  so  that  the  developer  can  measure  the  actual  results. 

To  execute  Buylt  agents  in  Test  mode,  the  developer  should: 

•  Select  View  >  Agents.  A  list  of  all  agents  appears. 

•  For  each  agent,  select  the  agent  to  test  and  choose  Actions  >  Test. 

•  A  test  report  appears  stating  the  number  of  documents  that  the  selected  agent  processes  and 
what  actions  it  performs  on  the  document  data. 

•  Verify  that  each  agent’s  processes  and  actions  are  correct 

To  execute  Buylt  agents  in  Run  mode,  the  developer  should: 

•  Select  View  >  Agents.  A  list  of  all  agents  appears. 

•  For  each  agent,  select  the  agent  to  test  and  choose  Actions  >  Run. 

•  Verify  that  the  selected  document(s)  for  each  agent  are  modified  as  required. 

4.8  Navigators.  Navigators  are  graphical  interface  and  design  objects  that  allow  users  to 
navigate  through  a  database  and  its  data  using  hotspots. 

•  To  quick-test  a  Buylt  navigator,  die  developer  should: 

•  Select  View  >  Design. 

•  Select  Design  and  then  Navigators  in  the  Navigation  pane.  A  list  of  all  navigators  appears. 

•  For  each  navigator,  double-click  the  navigator  to  open  it;  then  choose  Design  >  Test 
Navigator. 

•  Verify  that  each  navigator  performs  as  required. 

4.9  Application  Performance.  The  developer  weighs  the  advantages  of  implementing 
design  features  against  tradeoffs  in  database  performance.  It  is  important  to  evaluate  tiie  speed  at 
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which  views  and  documents  are  displayed  and  to  listen  to  the  users’  impressions  of  performance. 
Three  areas  that  can  easily  bog  dovm  speed  are  the  view  display  time,  document  display  time, 
and  formula  and  script  run  time. 

To  improve  view  display  time,  the  developer  checks  that  the  following  guidelines  were  used 
to  create  Buylt  views. 

•  Select  specific  documents  for  view,  rather  that  use  a  selection  formula  such  as  SELECT 
@ALL. 

•  Simplify  view  selection  formulas. 

•  Avoid  using  @Today  and  @Now  because  they  must  be  recalculated  each  time  the  view  is 
opened. 

•  Avoid  cascading  views  because  they  slow  down  view  regeneration. 

•  Avoid  displaying  unread  marks  at  every  level  unless  it’s  critical  to  the  user. 

•  Reduce  the  number  of  views  by  adding  columns  that  allow  users  to  sort  documents  at  will. 

•  Place  categorized  columns,  sorted-uncategorized  columns,  and  nonsorted  columns  in  order 
from  left  to  right. 

•  Use  field  values  rather  than  formulas  in  columns. 

To  improve  document  display  time,  the  developer  checks  that  the  following  guidelines  were 
used  to  create  Buylt  documents. 

•  Avoid  large  bitmaps  or  graphics. 

•  Avoid  the  form  property  “Automatically  refresh  fields,”  use  “Refresh  fields  on  keyword 
change”  or  write  a  LotusScript  field  event. 

•  Avoid  long  tables  with  many  computed  fields. 

•  Use  @DbColumn  or  @DbLookup  formulas  sparingly. 

•  Keep  formulas  for  “hide  when”  conditions  as  simple  as  possible. 

•  Avoid  recalculating  fields  if  possible  or  change  such  fields  to  computed-when-composed 
fields. 
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•  Set  field  values  through  Lotus  Script  form  events  rather  than  through  conditional  formulas 
in  the  field  itself  when  appropriate. 

•  Minimize  the  number  of  fields,  especially  hidden  fields,  and  use  form  events  rather  than 
field  formulas  to  execute  processing  logic  and  avoid  uimecessary  recalculations. 

To  improve  formula  and  script  run  time,  the  developer  checks  that  the  following  guidelines 
were  used  to  create  Buylt  formulas  and  scripts. 

•  Replace  long  ©function  formulas  with  shorter  LotusScript  programs. 

•  Use  LotusScript  front-end  UI  classes  only  for  form  navigation  and  other  user-interface 
simulations.  Use  the  back-end  database  classes  for  data  manipulation. 

•  Replace  @  V2If  wifii  @If  in  formulas  when  appropriate. 

•  Use  ©Prompt  to  prompt  the  user  for  information  to  narrow  down  the  search  when  doing 
lookups  with  ©functions. 

•  Use  ©Sum  to  add  a  set  of  numbers  or  number  lists  and  to  return  the  total  rather  than  using 
longer  formulas. 

•  Plan  and  design  lookups  to  external  data  sources  with  performance  and  response  time  in 
mind. 

5.  Beta  Testing 

The  best  approach  for  beta-testing  Buylt  for  functionality  is  to  test  the  system  with  a  small 
group  of  users  [10,  11].  This  group  of  users  should  be  composed  of  6  to  12  testers  who 
understand  the  workflow  of  a  purchase  request  from  an  end  user,  procurement,  budget,  or 
logistics  point  of  view.  These  testers  need  not  have  any  experience  using  Lotus  Notes.  The 
duration  of  the  testing  phase  is  plarmed  from  20  March  1997  through  14  April  1997. 

The  testers  examine  Buylt  by  using  a  list  of  specific  tasks  designed  to  check  the  system’s 
effectiveness,  value,  and  proper  function  in  regard  to  the  high-level  requirements  identified  in 
“Buylt  Software  Requirements  Analysis”  [3].  Table  1  gives  a  brief  description  of  the  eight 
requirements  identified  as  critical  for  an  operational  version  of  Buylt. 
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Table  1.  Functions  to  Be  Validated  Through  Usability  Testing 


Function 

Description 

Security 

Security  provides  measures  to  prevent  unauthorized  access  to 
the  system  and  its  data;  it  ensures  that  authorized  users  can 
perform  only  the  tasks  allowed  in  their  roles. 

Purchase  Request 
Preparation 

Purchase  request  preparation  provides  a  means  for  the 
requesters  and  functional  users  to  enter  and/or  edit  relevant 
information  pertaining  to  a  purchase  request. 

Automated  Request 
Routing 

Automated  request  routing  provides  a  process  that  automatically 
directs  a  purchase  request  through  a  prearranged  series  of 
functional  areas. 

Electronic  Approval 

Electronic  approval  provides  a  methodology  for  approving 
officials  and  functional  users  to  electronically  approve  or  reject 
a  purchase  request. 

Receive/ Accept  Order 

Receive/accept  an  order  provides  a  means  for  Receiving  to 
notify  requesters  of  shipment  arrival  and  for  the  purchaser  to 
accept  or  decline  an  order. 

Request  Tracking 

Request  tracking  allows  users  to  track  the  status  of  active 
purchase  requests  currently  in  the  system. 

Legacy  System 

Interface 

Legacy  system  interfaces  implement  automated  interfaces  to 
SOMARDS  and  SAACONS  legacy  systems. 

Reporting 

Reporting  provides  the  users  and  management  with  a  means  for 
reporting  cycle  time  and  costs. 

6.  User  Testing  Plan  Task  List 


Testing  is  the  process  of  analyzing  an  application  to  detect  the  difference  between  existing 
and  required  conditions  and  to  evaluate  the  features  of  the  application  [12,  13],  The  testing  is 
accomplished  in  an  organized  manner  by  employing  a  user  testing  plan  task  list.  This  list 
contains  specific  tasks  that  a  user  normally  executes  during  the  purchase  request  process  cycle. 
These  tasks  are  derived  from  the  “Buylt  Software  Requirements  Analysis”  [3],  and  the  “Buylt 
Detailed  Design  Report”  [4].  The  prototype  environment  is  Windows;  therefore,  all  tasks  are 
directed  toward  the  personal  computer  (PC)  environment.  The  task  flow  follows  the  cognitive 
processes  that  a  user  employs  whra  placing  a  purchase  request. 
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Tasks  are  performed  by  its  corresponding  role(s)  assigned  to  a  user.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiver.  During  testing,  as  each  task  is  executed,  the  user  in  the  corresponding  role  assignment 
evaluates  the  results  and  either  verifies  that  the  task  was  accomplished  successfully  or  reports  the 
error  via  the  Buylt  discussion  database.  Testing  is  successfully  completed  when  the  users  in  their 
corresponding  roles  have  correctly  executed  all  tasks. 

Tasks  are  performed  by  the  corresponding  role  assignments: 

•  Task  0.1  -  all  roles. 

•  Task  1.0  -  requester. 

•  Task  2.0  -  budget  analyst. 

•  Task  3.0  -  supervisor  has  full  editing  rights  on  all  fields, 

budget  analyst  has  editing  rights  on  fund  source  fields, 
property  book  officer  has  editing  rights  on  item  tags, 
contracting  officer  has  editing  rights  on  buyer  assignment, 
receiving  has  editing  rights  on  item  tags,  and 
other  approveifs). 

•  Task  4.0  -  requester. 

•  Task  5.0  -  contracting  officer  and  buyer. 

•  Task  6.0  -  receiving. 

•  Task  7.0  -  all  roles. 

•  Task  8.0  -  all  roles. 

See  die  Appendix  for  the  task  worksheets  defined  for  each  role.  Each  segment  clearly 
presents  the  tasks  and  subtasks  as  a  set  of  checklists  for  use  in  a  field-test  environment  The 
worksheets  are  suitable  for  photocopying.  Thus,  completed  sets  of  usability  test  data  can  be 
collected,  analyzed,  and  stored,  providing  feedback  for  system  adjustment  and  enhancement  at  a 
later  date. 
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6.1  Task  0.1;  Log  Onto  Buylt.  Logon  is  used  by  all  roles.  The  logon  process  provides 
security  by  allowing  only  authorized  users  to  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  The  following  checklist  assists  the  user  in  determining  if  this  task  was 
accomplished  successfully. 

(1)  Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop  workspace? 

(2)  Can  the  user  log  onto  Lotus  Notes  using  a  password? 

(3)  Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct  password? 

(4)  Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

(5)  Can  the  user  log  onto  Buylt  using  a  password? 

(6)  Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

(7)  Does  the  “About  This  Database”  appear  when  the  user  logs  onto  Buylt  for  the  first  time? 

(8)  Can  the  user  display  the  Buylt  startup  screen? 

6.2  Task  1.0:  Prepare  Purchase  Request  The  user  creates  a  new  purchase  request  by 
clicking  on  the  “Create  New  Request”  button.  When  the  “Purchase  Request  Entry”  screen  is 
displayed,  some  of  the  requester  information  is  automatically  displayed.  The  user  enters  the 
remaining  requester  information,  item  details,  vendor  information  (if  known  at  this  time),  and  the 
date  the  items  are  required  by.  The  fund  source,  delivery  information,  and  attachment 
information  complete  the  information  for  the  request.  The  user  submits  the  request  to  his/her 
supervisor.  Supervisory  approval  puts  the  request  into  the  procurement  cycle. 
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This  task  is  successfully  completed  when  the  user  can  correctly  submit  the  purchase  request 
to  his/her  designated  supervisor  for  approval.  Table  2  summarizes  the  subtasks  of  “Prepare 
Purchase  Request,”  gives  the  role  assigned  to  the  subtask,  and  indicates  the  segment  of  this  report 
that  contains  a  checklist  to  assist  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  2.  Subtasks  for  Prepare  Purchase  Request 


Subtask 

Role 

Section  Number 

Create  New  Purchase  Request 

Requester 

6.2.1 

Fill  in  Purchase  Request 

Requester 

6.2.2 

Fill  in  Fund  Source 

Requester 

6.2.3 

Approve  Purchase  Request 

Requester 

6.2.4 

62.1  Subtask  1.1:  Create  New  Purchase  Request. 

(1)  Are  the  fields  clearly  labeled  and  easy  to  understand?  (Please  note  that  the  field  names 
used  in  this  testing  plan  may  not  exactly  match  the  field  names  that  the  user  will  see  on 
the  form.) 

(2)  Are  the  fields  arranged  in  a  way  that  makes  sense  and  follows  the  user’s  process  for 
creating  a  purchase  request? 

(3)  Are  the  following  Requester  Info  fields  automatically  displaying  the  correct  user 
information? 

•  Name  -  contains  the  user’s  name. 

•  Office  Symbol  -  contains  the  user’s  office  symbol. 

•  Phone  -  contains  the  user’s  telephone  number. 

•  Request  Date  -  contains  today’s  date. 
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6.2.2  Subtask  1.2:  Fill  in  Purchase  Request. 

(1)  Can  information  be  entered  correctly  into  editable  Requester  Info  fields? 

•  Date  Required  -  date  formatted  as  MM/DD/YY. 

•  Priority  -  a  selected  priority  code. 

(2)  Can  information  be  entered  correctly  into  editable  Vendor  Info  fields? 

•  Company  Name  -  text  field. 

•  Phone  No.  -  text  field. 

•  Address  -  text  field. 

•  Fax  No.  -  text  field. 

•  City  -  text  field. 

•  State  -  text  field. 

•  Zip  Code  -  text  field. 

•  Point  of  Contact  (POC)  -  text  field. 

(3)  Is  the  Item  No.  automatically  displaying  the  correct  sequential  number  from  1  through 
16? 

(4)  Can  information  be  entered  correctly  into  editable  Items  fields? 

•  Description  -  text  field. 

•  Tag  -  text  field. 

•  U.L  -  selected  unit  of  issue. 

•  Unit  Estimated  Cost  -  numeric  field  with  two  decimal  places. 

•  Total  Estimated  Cost  -  numeric  field  with  two  decimal  places. 

(5)  Are  the  following  Delivery  information  fields  automatically  displaying  the  correct  user 
information? 
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•  Name  -  contains  the  user’s  name. 

•  Phone  Number  -  contains  the  user’s  telephone  number. 

•  Bldg.  -  contains  the  user’s  location. 

•  Room  Number  -  contains  the  user’s  room  number. 

(6)  Can  the  user  enter  sole  source  justification  information  and/or  item  specifications  in  the 

Attachments  information  fields? 

6.2.3  Subtask  13:  Fill  in  Fund  Source. 

Can  information  be  entered  correctly  into  editable  Funds  source  fields? 

•  Job  No  -  text  field. 

•  EOR  -  text  field. 

63.4  Subtask  1.4:  Approve  Purchase  Request. 

Can  the  completed  purchase  request  be  submitted  to  the  user’s  supervisor  by  clicking  the 
Submit  button? 

63  Task  2.0:  Approve  Funds.  This  major  process  interfaces  to  the  SOMARDS  legacy 
system  and  is  transparent  to  the  user.  A  “Build  Block”  process  is  executed  at  the  start  of  the  day 
and  creates  the  transaction  block  used  by  Buylt  for  that  day.  As  certifiable  purchase  requests  are 
created  during  die  course  of  the  day,  the  “Certify  Funds”  process  queries  SOMARDS  and  returns 
a  message  to  either  certify  or  reject  the  request.  At  the  end  of  the  day,  the  “Reconcile”  process 
block  is  executed  to  balance  the  transaction  block. 

This  task  is  successfully  completed  when  the  Accounting  Classification  field  is  completed  (if 
there  are  sufficient  funds)  or  when  a  rejection  explanation  is  provided  for  insufficient  funds  or  for 
an  incorrect  Job  No.  Table  3  lists  the  subtasks  of  “Approve  Funds,”  gives  the  role  assigned  to 
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Table  3.  Subtasks  for  Approve  Funds 


Subtask 

Role 

Section  Number 

Approve  Fund  Source 

Budget  Analyst 

6.3.1 

Approve  Actual  Cost 

Budget  Analyst 

6.3.2 

Certify  Funds 

Budget  Analyst 

6.3.3 

Build  Block 

Budget  Analyst 

6.3.4 

Reconcile 

Budget  Analyst 

6.3.5 

the  subtask,  and  indicates  the  segment  of  this  report  that  contains  a  checkhst  to  assist  the  user  in 
determining  if  this  task  was  accomplished  successfully. 


6.3.1  Subtask  2.1:  Approve  Fund  Source. 

(1)  Does  the  Job  No.  field  on  the  purchase  request  contain  the  correct  information  that 
corresponds  to  the  Job  No.  assigned  to  the  requester’s  orgamzation? 

(2)  Is  the  EOR  correct  and  in  correspondence  with  the  items  requested  for  purchase? 

632  Subtask  2.2:  Approve  Actual  Cost. 

Does  the  Total  Estimated  Cost  field  contain  the  correct  amount? 


6.33  Subtask  2.3:  Certify  Funds 

(1)  Does  SOMARDS  contain  sufficient  funds  in  the  Job  No.  account  to  cover  the  amount 
contained  in  the  Total  Estimated  Cost  field? 

(2)  If  there  are  sufficient  funds,  is  the  purchase  request  certified  by  displaying  the  correct 
Accounting  Classification  number? 


(3)  If  tiiere  are  insufficient  funds,  is  the  purchase  request  rejected  by  leaving  the  Accounting 
Classification  field  blank  and  by  providing  an  explanation  for  the  rejection? 

63.4  Subtask  2.4:  Build  Block. 

Is  a  correctly  formatted  transaction  block  built  each  day? 

633  Subtask  2.5:  Reconcile. 

Is  the  transaction  block  correctly  reconciled  at  the  end  of  each  day? 

6.4  Task  3.0;  Obtain  Approvals.  For  each  assigned  role,  a  list  of  purchase  requests  is 
displayed  on  the  Buylt  startup  screen  awaiting  approval.  By  clickmg  on  the  Pending  button,  the 
user  refireshes  the  startup  screen  to  display  any  requests  that  require  his/her  action.  The  user  then 
selects  a  request  for  approval.  The  user,  as  a  supervisor  or  other  approving  official,  may: 

•  Open  a  selected  request. 

•  Review  the  request. 

•  Close  the  request  and  save  the  approval  for  later. 

•  Attach  his/her  approval  to  the  request. 

•  Deny  approval  and  raiter  an  explanation. 

Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment.  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  die  request. 

This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  Table  4  lists  the  subtasks  of  “Obtain 
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Table  4.  Subtasks  for  Obtain  Approvals 


Subtask 

Role 

Section  Number 

Approve  Special  Items 

•  Supervisor  has  full  editing  rights  on 
all  fields. 

•  Budget  analyst  has  editing  rights  on 
fund  source  fields. 

•  Property  book  officer  has  editing 
rights  on  item  tags. 

•  Contracting  officer  has  editing  rights 
on  buyer  assignment. 

•  Receiving  has  editing  rights  on  item 
tags. 

6.4.1 

Attach  Item  Tag 

Same  as  above. 

6.4.2 

Property  Approval 

Same  as  above. 

6.4.3 

Approvals,”  gives  the  role  assigned  to  the  subtask,  and  indicates  the  segment  of  this  report  that 
contains  a  checklist  to  assist  the  user  in  determining  if  this  task  was  accomplished  successfully. 


6.4.1  Subtask  3.1:  Approve  Special  Items. 

(1)  Is  the  information  for  each  purchase  request  on  the  Buylt  startup  screai  easy  to  read? 

(2)  Are  all  the  requests  displayed  on  the  startup  screen  awaiting  approval  from  the  user’s 
assigned  role? 

(3)  Are  there  any  requests  missing  from  the  startup  screen? 

(4)  For  each  column  on  the  startup  screen,  is  the  information  for  each  request  correct? 

(5)  Is  each  column  on  the  startup  screen  returning  the  correct  data  type  values? 
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(6)  Is  each  column  on  the  startup  screen  displaying  all  the  information  that  is  contained  in 
it? 

(7)  Are  the  contents  of  the  columns  on  the  startup  screen  aligned  properly? 

(8)  Are  the  purchase  requests  in  the  right  order? 

(9)  On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to  understand?  Please 
note  that  the  field  names  used  in  this  testing  plan  may  not  exactly  match  the  field  names 
that  the  user  will  see  on  the  form. 

(10)  Are  the  fields  arranged  in  a  way  that  makes  sense  and  facilitates  movement  through  the 
form? 

(11)  If  in  a  supervisor  role,  can  all  fields  be  edited  correctly? 

(12)  After  the  supervisor  approves  the  request,  is  a  correct  Document  Reference  Number 
automatically  generated? 

(13)  If  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be  edited  correctly? 

(14)  If  in  a  contracting  officer  role,  can  only  the  buyer  assignment  be  entered  correctly? 

(15)  Can  the  user  close  the  request  and  save  its  approval  for  some  later  time? 

(16)  Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

(17)  Can  the  user  approve  the  request? 

(18)  If  the  request  is  denied,  is  it  routed  back  to  the  requester? 
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(19)  If  the  request  is  approved,  is  it  routed  to  the  next  assigned  approver? 


6.4^  Subtask  3.2:  Attach  Item  Tag. 

In  a  property  book  officer  role,  can  only  item  tags  be  entered  correctly  and  no  other  fields  be 
edited? 

6.43  Subtask  33:  Property  Approval. 

hi  a  receiving  role,  can  only  tag  items  be  edited  correctly? 

6.5  Task  4.0:  Edit  Purchase  Request  The  rejected  purchase  request  is  returned  to  the 
requester.  The  user  sees  the  request  displayed  on  the  Buylt  startup  screen  and  selects  the  request 
for  editing.  The  Purchase  Request  Entry  screen  is  displayed  so  that  the  user  can  enter 
corrections.  Depending  on  where  the  rejection  came  from  and  how  far  along  the  approval 
process  the  request  has  traveled,  the  user  is  only  allowed  to  edit  only  certain  fields  within  the 
request. 

This  task  is  successfully  completed  when  the  user  can  successfully  correct  the  purchase 
request  and  submit  the  request  for  the  remaining  approvals.  Table  5  lists  the  subtasks  of  “Edit 
Purchase  Request,”  gives  the  role  assigned  to  the  subtask,  and  indicates  the  segment  of  this  report 
that  contains  a  checklist  to  assist  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  5.  Subtasks  for  Edit  Purchase  Request 


Subtask 

Role 

Section  Number 

Edit  Rejected  Purchase  Request 

Requester 

6.5.1 

Cancel  Purchase  Request 

Requester 

6.5.2 
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d.5./  Subtask  4.1 :  Edit  Rejected  Purchase  Request. 


(1)  If  the  supervisor  denied  approval,  can  the  user  correctly  edit  all  of  the  fields? 

(2)  If  the  budget  analyst  denied  certification,  can  the  user  correctly  edit  only  the  fund  source 
fields? 

(3)  If  one  of  the  approvers  denied  approval,  can  the  user  correctly  edit  only  the  fields  related 
to  the  rejection? 

(4)  If  the  contracting  officer  denies  approval,  can  the  user  correctly  edit  Vendor,  Item,  or 
Attachment  information  related  to  the  rejection? 

6.5.2  Subtask  42:  Cancel  Purchase  Request. 


(1)  Can  the  user’s  supervisor  cancel  a  purchase  request? 

(2)  Can  the  user  cancel  the  purchase  request? 

(3)  Are  no  other  approvers  allowed  to  cancel  the  purchase  request? 

6.6  Task  5.0:  Prepare  Purchase  Order.  This  task  is  successfully  completed  when  the 
SAACONS  information  appears  on  the  purchase  request  and  when  receiving  is  notified  of  the 
pending  shipment.  Table  6  lists  the  subtasks  of  “Prq)are  Purchase  Order,”  indicates  the  role 
assigned  to  the  subtask,  and  gives  the  segment  of  this  report  that  contains  a  checklist  to  assist  the 
user  in  determining  if  this  task  was  accomphshed  successfully. 
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Table  6.  Subtasks  for  Prepare  Purchase  Order 


Subtask 

Role 

Section  Number 

Assign  Buyer 

Contracting  Officer/Buyer 

6.6.1 

Approve  Purchase 

Contracting  Officer/Buyer 

6.6.2 

Get  Actual  Cost 

Contracting  Officer/Buyer 

6.6.3 

Get  Purchase  Order 

Contracting  Officer/Buyer 

6.6.4 

6.6.1  Subtask  5.1:  Assign  the  Buyer. 

(1)  Has  the  contracting  officer  assigned  a  buyer  for  the  purchase  request? 

(2)  Does  the  buyer  information  appear  in  the  vendor  information  on  the  purchase  request? 
6.62  Subtask  5.2:  Approve  Purchase. 

(1)  Has  the  selected  buyer  approved  the  purchase  request? 

(2)  Has  the  selected  buyer  created  award  information  in  SAACONS? 

(3)  If  the  buyer  denied  approval,  is  the  rejected  request  returned  to  the  contracting  officer? 

6.6.3  Subtask  53:  Get  Actual  Costs. 

(1)  Was  the  correct  award  information  downloaded  from  SAACONS  to  the  purchase 
request? 

(2)  Do  the  Actual  Costs  fields  on  the  purchase  request  contain  the  correct  amounts? 

6.6.4  Subtask  5.4:  Get  Purchase  Order.  Has  the  completed  purchase  request  been 
forwarded  to  receiving  pending  receipt  of  shipment? 
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6.7  Task  6.0:  Receive  Shipment  Sometime  after  the  completed  purchase  request  is 
forwarded  to  receiving,  the  shipment  is  delivered  to  the  warehouse.  Receiving  marks  the  request 
as  “received”  and  checks  off  any  tagged  items  once  tiiey  are  properly  accounted  for.  At  this 
point,  Buylt  notifies  the  requester  of  receipt  and  allows  the  user  to  accept  or  return  items  after 
they  are  delivered. 

This  task  is  successfully  completed  when  receiving  marks  the  request  as  received  and  checks 
off  any  tagged  items,  and  when  Buylt  notifies  the  user  of  receipt  and  allows  the  user  to  either 
accept  or  return  the  items.  After  the  user  accepts  or  returns  the  items,  Buylt  marks  the  purchase 
request  as  closed.  Table  7  lists  the  subtasks  of  “Receive  Shipment,”  gives  the  role  assigned  to 
the  subtask,  and  indicates  the  segment  of  this  report  that  contains  a  checklist  to  assist  the  user  in 
determining  if  this  task  was  accomplished  successfully. 


Table  7.  Subtasks  for  Receive  Shipment 


Subtask 

Role 

Section  Number 

Receive  Order 

Receiving 

6.7.1 

Tag  Received  Items 

Receiving 

6.7.2 

Accept  Shipment 

Receiving 

6.7.3 

6.7.1  Subtask  6.1:  Receive  Order.  Has  receiving  marked  the  request  as  correctly  received? 

6.7.2  Subtask  6J:  Tag  Received  Items.  Has  receiving  properly  accounted  for  all  tagged 
items  and  correctly  checked  them  off? 

6.7.3  Subtask  63:  Accept  Shipment. 

(1)  Has  Buylt  notified  the  requester  of  receipt  of  the  purchase  request? 

(2)  Does  Buylt  allow  the  user  to  accept  items? 
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(3)  Does  Buylt  allow  the  user  to  return  items? 

(4)  After  the  user  accepts  or  returns  items,  does  Buylt  mark  tiie  purchase  request  as  closed 
and  remove  it  from  the  active  system? 

6.8  Task  7.0:  Submit  Inquiries.  Clicking  on  the  Status  button  displays  the  Status  Inquiry 
screen.  This  screen  lists  the  requests  that  were  “touched”  by  the  user  either  as  a  requester  or  as 
an  approving  official.  Requests  are  listed  by  Document  Reference  Number  and  show  the 
requester,  current  approval  status,  how  long  the  request  is  in  the  current  status,  and  the  date 
required.  By  selecting  a  specific  document,  the  user  views  all  purchase  request  information 
available  for  that  document.  Additionally,  the  user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  described,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 

This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  can  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  from 
the  Reports  screen  successfully.  Table  8  lists  the  subtasks  of  “Submit  Inquiries,”  gives  the  role 
assigned  to  the  subtask,  and  indicates  the  segment  of  this  rq)ort  that  contains  a  checklist  to  assist 
the  user  in  determining  if  this  task  was  accomplished  successfully. 


Table  8.  Subtasks  for  Submit  Inquiries 


Subtask 

Role 

Section  Number 

Show  Inbox 

All  Roles 

6.8.1 

Show  Report  Request 

All  Roles 

6.8.2 

Show  Status 

All  Roles 

6.8.3 

Generate  Report 

All  Roles 

6.8.4 
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6.8.1  Subtask  7.1:  Show  Inbox. 


(1)  Is  the  Startup/Inbox  User  screen  displayed  after  the  user  clicks  on  the  Pending  button? 

(2)  Is  the  information  for  each  purchase  request  displayed  in  the  inbox  easy  to  read? 

(3)  Are  all  the  requests  displayed  in  the  inbox  awaiting  approval  from  the  user’s  assigned 
role? 

(4)  Are  there  any  requests  missing  from  the  inbox? 

(5)  For  each  column  in  the  inbox,  is  the  information  for  each  request  correct? 

(6)  Is  each  column  in  the  inbox  returning  the  correct  data  type  values? 

(7)  Is  each  column  in  the  inbox  displaying  all  of  the  mformation  that  is  contained  in  it? 

(8)  Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

(9)  Are  the  purchase  requests  in  the  right  order? 

6.8.2  Subtask  7:2:  Show  Report  Request. 

(1)  Can  the  user  select  and  display  any  purchase  request  from  the  inbox? 

(2)  Can  the  user  only  view  and  not  edit  the  displayed  purchase  request? 

(3)  On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to  understand?  Please  note 
that  the  field  names  used  in  this  testing  plan  may  not  exactly  match  the  field  names  that 
the  user  will  see  on  the  form. 
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(4)  Are  the  fields  arranged  in  a  way  that  makes  sense? 

6.8  J  Subtask  7.3:  Show  Status. 

(1)  Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the  Status  button? 

(2)  Is  the  information  for  each  purchase  request  displayed  on  the  Status  Inquiry  screen  easy 
to  read? 

(3)  Are  all  the  requests  displayed  on  the  Status  Inquiry  screen  “touched”  by  the  user  in  some 
manner? 

(4)  Are  there  any  requests  missing  from  the  Status  Inquiry  screen? 

(5)  For  each  column  on  the  screen,  is  the  information  for  each  request  correct? 

(6)  Is  each  column  on  the  screen  returning  the  correct  data  type  values? 

(7)  Is  each  column  on  the  screen  displaying  all  of  the  information  that  is  contained  in  it? 

(8)  Are  the  contents  of  the  columns  on  the  screen  aligned  properly? 

(9)  Are  the  purchase  requests  in  the  right  order? 

6.8.4  Subtask  7.4:  Generate  Report. 

(1)  Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a  purchase  request  and  clicks  on 
the  Reports  button? 

(2)  Is  the  information  displayed  in  the  report  easy  to  read? 
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(3)  Is  the  information  in  the  report  in  the  correct  order? 


(4)  For  each  column  in  the  report,  is  the  information  correct? 

(5)  Is  each  column  in  the  report  returning  the  correct  data  type  values? 

(6)  Is  each  column  in  the  report  displaying  all  of  the  information  that  is  contained  in  it? 

(7)  Are  the  contents  of  the  columns  in  the  report  aligned  properly? 

6.9  Task  8.0:  Exit  Buylt.  Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the 
system  is  properly  closed  and  prevents  any  unauthorized  person  from  gaining  access  to  the 
system. 

This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  The  following  checklist  assists  the  user  in  determining  if  this  task  was 
accomplished  successfully. 

•  By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the  screen,  does  the  user  return  to 
the  PC’s  desktop  workspace? 
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Intentionally  left  blank. 
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Appendix: 

Buylt  Task  Worksheets  for  Defined  Roles 
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Requester  Role 


Task  List  for  Testing  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  performs  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  flie  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 

Task  0.1:  Log  Onto  Buylt 

Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  Table  A-1  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully: 

The  user  creates  a  new  purchase  request  by  clicking  on  the  “Create  New  Request”  button. 
When  the  “Purchase  Request  Entry”  screen  is  displayed,  some  of  the  requester  information  is 
automatically  displayed.  The  user  enters  the  remaining  requester  information,  item  details, 
vendor  information  (if  known  at  this  time),  and  the  date  by  which  the  items  are  required.  The 
fund  source,  delivery  information,  and  attachment  information  complete  the  information  for  the 
request.  After  submitting  the  request  to  the  user’s  supervisor,  the  supervisory  approval  puts  the 
request  into  the  procurement  cycle. 
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Table  A-1.  Task  1.0:  Prepare  Purchase  Request 


Task  Number 

Task 

Yes 

No  1 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■ 

■ 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

■■ 

0.1.3 

Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct 
password? 

■ 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

IH 

0.1.7 

Does  the  “About  This  Database”  appear  when  the  user  logs 
onto  Buylt  for  the  first  time? 

■ 

0.1.8 

Can  the  user  display  the  Buylt  startup  screen? 

This  task  is  successfully  completed  when  the  user  can  correctly  submit  the  purchase  request 
to  his/her  designated  supervisor  for  approval.  Tables  A-2  through  A-5  assist  the  user  in 
determining  if  this  task  was  accomplished  successfully. 


Table  A-2.  Subtask  1.1:  Create  New  Purchase  Request 


Task  Number 

Task 

Yes 

No 

1.1.1 

Are  the  fields  clearly  labeled  and  easy  to  understand?  Please 
note  that  the  field  names  used  in  this  testing  plan  may  not 
exactly  match  the  field  names  that  the  user  will  see  on  the  form. 

1 

1.1.2 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  follow  the 
user’s  process  for  creating  a  purchase  request? 

■ 

1.1.3 

For  Requester  Info,  does  the  Name  field  automatically  display 
the  user’s  name? 

1.1.4 

For  Requester  Info,  does  the  Office  Symbol  field  automatically 
display  the  user’s  office  symbol? 

■ 

1.1.5 

For  Requester  Info,  does  the  Phone  field  automatically  display 
the  user’s  phone  number? 

1.1.6 

For  Requester  Info,  does  the  Request  Date  field  automatically 
display  today’s  date? 
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Table  A-3.  Subtask  1^:  FlU  in  Purchase  Request 


1  Task  Number 

Task 

Yes  No 

1.2.1 

For  Requester  Info,  can  the  information  entered  into  the  Date 
Required  field  be  entered  as  a  date  formatted  as  MM/DD/YY? 

1.2.2 

For  Requester  Mo,  can  a  selected  priority  code  be  entered  into 
the  Priority  field? 

1.2.3 

For  Vendor  Mo,  can  text  Mormation  be  entered  into  the 

Company  Name  field? 

1.2.4 

For  Vendor  Mo,  can  text  Mormation  be  entered  into  the  Phone 

No  field? 

1.2.5 

For  Vendor  Mo,  can  text  Mormation  be  entered  Mo  the  Address 
field? 

1.2.7 

For  Vendor  Mo,  can  text  Mormation  be  entered  Mo  the  City 
field? 

1.2.8 

For  Vendor  Mo,  can  text  Mormation  be  entered  Mo  the  State 
field? 

1.2.9 

For  Vendor  Mo,  can  text  Mormation  be  entered  Mo  the  Zip 

Code  field? 

1.2.10 

For  Vendor  Mo,  can  text  Mormation  be  entered  Mo  the  POC 
field? 

1.2.11 

Is  the  Item  No  automatically  displaying  the  correct  sequential 
number  from  1  through  16? 

1.2.12 

For  Items  Mormation,  can  text  Mormation  be  entered  Mo  the 
Description  field? 

1.2.13 

For  Items  Mormation,  can  text  Mormation  be  entered  Mo  the 

Tag  field? 

1.2.14 

For  Items  Mormation,  can  a  selected  unit  of  issue  be  entered  Mo 
the  U.I.  field? 

1.2.15 

For  Items  Mormation,  can  a  number  with  two  decMal  places  be 
entered  Mo  the  UM  Estimated  Cost  field? 

1.2.16 

For  Items  Mormation,  can  a  number  with  two  decimal  places  be 
entered  Mo  the  Total  EstMated  Cost  field? 

1.2.17 

For  Delivery  Mormation,  is  the  user’s  name  automatically 
displayed  in  the  Name  field? 

1.2.18 

For  Delivery  Mormation,  is  the  user’s  telephone  number 
automatically  displayed  in  the  Phone  Number  field? 

1.2.19 

For  Delivery  Mormation,  is  the  user’s  location  automatically 
displayed  in  the  Bldg  field? 

1.2.20 

For  Delivery  Mormation,  is  the  user’s  room  number 
automatically  displayed  in  the  Room  Number  field? 

1.2.21 

Can  the  user  enter  sole  source  justification  Mormation  and/or 
item  specifications  in  the  Attachments  Mormation  fields? 
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Table  A-4.  Subtask  13:  Fill  in  Fund  Source 


Task  Number 

Task 

Yes 

No 

1.3.1 

For  Funds  source,  can  text  information  be  entered  into  the  Job  No 
field? 

■ 

■ 

1.3.2 

For  Funds  source,  can  text  information  be  entered  into  the  EOR 
field? 

■ 

■ 

Table  A-5.  Subtask  1.4:  Approve  Purchase  Request 


Task  Number 

Task 

Yes 

No 

1.4.1 

Can  the  completed  purchase  request  be  submitted  to  the  user’s 
supervisor  by  clicking  the  Submit  button? 

■ 

Task  4.0:  Edit  Purchase  Request 

The  rejected  purchase  request  is  returned  to  the  requester.  The  user  sees  the  request 
displayed  on  the  Buylt  startup  screen  and  selects  the  request  for  editing.  The  Purchase  request 
Entry  screen  is  displayed  so  that  the  user  can  enter  corrections.  Depending  on  where  the 
rejection  came  from  and  how  far  along  the  approval  process  the  request  has  traveled,  the  user  is 
only  allowed  to  edit  certain  fields  within  the  request 

This  task  is  successfully  completed  when  the  user  can  successfully  correct  the  pvurchase 
request  and  submit  the  request  for  the  remaining  approvals.  Tables  A-6  and  A-7  assist  the  usar  in 
determining  if  this  task  was  accomplished  successfully. 


Table  A-6.  Subtask  4.1:  Edit  Rejected  Purchase  Request 


Task  Number 

Task 

Yes 

No  1 

4.1.1 

If  the  supervisor  denied  approval,  can  the  user  correctly  edit  all  of 
the  fields? 

■ 

■ 

4.1.2 

If  the  budget  analyst  denied  approval,  can  the  user  correctly  edit 
only  the  fund  source  fields? 

■ 

■ 

4.1.3 

If  one  of  the  approvers  denied  approval,  can  the  user  correctly 
edit  only  the  fields  related  to  the  rejection? 

■ 

4.1.4 

If  the  contracting  officer  denies  approval,  can  the  user  correctly 
edit  Vendor,  Item,  or  Attachment  information  related  to  the 
rejection? 

■ 

1 

Table  A-7.  Subtask  4.2:  Cancel  Purchase  Request 


Task  Number 

Task 

Yes 

No  1 

4.2.1 

Can  the  user’s  supervisor  cancel  a  purchase  request? 

4.2.2 

Can  the  user  cancel  the  purchase  request? 

4.2.3 

Are  no  other  approvers  allowed  to  cancel  the  purchase  request? 

Task  7.0:  Submit  Inquiries 

Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
lengdi  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document.  Also,  the 
user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  described,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 
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This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  can  obtaiu  a  Cycle  Time  report  for  a  selected  purchase  request  from 
the  Reports  screen  successfully.  Tables  A-8  through  A- 11  assist  the  user  in  determining  if  this 
task  was  accomplished  successfully. 


Table  A*8.  Subtask  7.1:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/Inbox  User  screen  displayed  after  the  user  clicks  on 
the  Pending  button? 

7.1.2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

7.1.3 

Are  all  the  requests  displayed  in  the  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

7.1.6 

Is  each  column  in  the  inbox  returning  the  correct  data  type 
values? 

7.1.7 

Is  each  colunm  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

7.1.8 

Are  the  contents  of  the  colunms  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-9.  Subtask  7.2:  Show  Report  Request 


Task  Number 

Task 

Yes 

No 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  from  the 
inbox? 

■ 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

■ 

■ 

On  the  Liquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

Are  the  fields  arranged  in  a  way  that  makes  sense? 
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Table  A-10.  Subtask  73:  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

■ 

mm 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

■ 

■ 

HH 

Are  all  the  requests  displayed  on  the  Status  Inquiry  screen 
“touched”  by  the  user  in  some  manner? 

■ 

■ 

Are  there  any  requests  missing  from  the  Status  Inquiry  screen? 

■■ 

For  each  colunm  on  the  screen,  is  the  information  for  each  request 
correct? 

■  : 

Is  each  colunm  on  the  screen  returning  the  correct  data  type 
values? 

m 

Is  each  column  on  the  screen  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.3.8 

Are  die  contents  of  the  colunms  on  the  screen  aligned  properly? 

7.3.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-11.  Subtask  7.4:  Generate  Report 


Task  Number 

Task 

Yes 

No 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  the  Reports  button? 

■ 

7.4.2 

Is  the  information  displayed  in  the  report  easy  to  read? 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

7.4.5 

Is  each  column  in  the  report  returning  the  correct  data  type 
values? 

■ 

■ 

7.4.6 

Is  each  colunm  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.4.7 

Are  the  contents  of  the  colunms  in  the  report  aligned  properly? 

- 

LJ 
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Task  8.0:  ExitBuylt 

Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  unauthorized  person  from  gaining  access  to  the  system. 

This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  Table  A- 12  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table A-12.  Task 8.0:  ExitBuylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

■ 

Supervisor  Role 

Task  List  for  Testing  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  performs  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  the  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 

Task  0.1:  Log  Onto  Buylt 

Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  access  the  system  via  password  protection. 
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This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  Table  A- 13  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-13.  Task  3.0?  Obtain  Approvals 


Task  Number 

Task 

Yes 

No 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■ 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

0.1.3 

Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct  password? 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

0.1.7 

Does  the  “About  This  Database”  appear  when  the  user 

Logs  onto  Buylt  for  the  first  time? 

■ 

■ 

0.1.8 

Can  the  user  display  the  Buylt  startup  screai? 

ii 

For  each  assigned  role,  a  list  of  purchase  requests  is  displayed  on  the  Buylt  startup  screen 
awaiting  approval.  By  clicking  on  the  Pending  button,  the  user  refreshes  the  startup  screen  to 
display  any  requests  that  require  his/her  action.  The  user  then  selects  a  request  for  approval.  The 
user,  as  a  supervisor  or  other  approving  official,  may: 


•  open  a  selected  request. 

•  review  the  request. 

•  close  the  request  and  save  the  approval  for  later. 

•  attach  his/her  approval  to  the  request. 

•  Deny  approval  and  enter  an  explanation. 

Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  the  request. 
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This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  Table  A- 14  assists  the  user  in  determining  if 
this  task  was  accomplished  successfully. 

Task  7.0:  Submit  Inquiries 

Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
length  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document.  Also,  the 
user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  desaibed,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 

This  t?^sV  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  can  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  from 
the  Reports  screen  successfully.  Tables  A- 15  through  A- 18  assist  the  user  in  determining  if  this 
task  was  accomplished  successfully. 
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Table  A-14.  Subtask  3.1:  Approve  Special  Items 


3.1.1 

Is  the  information  for  each  purchase  request  on  the  Buylt  startup 
screen  easy  to  read? 

3.1.2 

Are  all  the  requests  displayed  on  the  startup  screen  awaiting 
approval  from  the  user’s  assigned  role? 

3.1.3 

Are  there  any  requests  missing  from  the  startup  screen? 

3.1.4 

For  each  column  on  the  startup  screen,  is  the  information  for  each 
request  correct? 

3.1.5 

Is  each  column  on  the  startup  screen  returning  the  correct  data 
type  values? 

3.1.6 

Is  each  column  on  the  startup  screen  displaying  all  the 
information  that  is  contained  in  it? 

3.1.7 

Are  the  contents  of  the  colunms  on  the  startup  screen  aligned 
properly? 

3.1.8 

Are  the  purchase  requests  in  the  right  order? 

3.1.9 

On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

3.1.10 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  that 
facilitates  movement  through  the  form? 

3.1.11 

If  in  a  supervisor  role,  can  all  fields  be  edited  correctly? 

3.1.12 

After  the  supervisor  approves  the  request,  is  a  correct  Document 
reference  Number  automatically  generated? 

3.1.13 

If  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be 
edited  correctly? 

3.1.14 

If  in  a  contracting  officer  role,  can  only  the  buyer  assignment  be 
entered  correctly? 

3.1.15 

Can  the  user  close  the  request  and  save  its  approval  for  some  later 
time? 

3.1.16 

Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

3.1.17 

Can  the  user  approve  the  request? 

3.1.18 

If  the  request  is  denied,  is  it  routed  back  to  the  requester? 

3.1.19 

If  the  request  is  approved,  is  it  routed  to  the  next  assigned 
approver? 

N/A  N/A 


N/A  N/A 


Table  A-15.  SubtaskT.l:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/Inbox  User  screen  displayed  after  the  user  clicks  on 
the  Pending  button? 

■ 

7.1.2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

■ 

7.1.3 

Are  aU  the  requests  displayed  in  the  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

■ 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

■ 

7.1.6 

Is  each  column  in  the  inbox  returning  the  correct  data  type 
values? 

7.1.7 

Is  each  column  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

7.1.8 

Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Ml. 

Table  A-16.  Subtask  7^:  Show  Report  Request 


Task  Number 

Task 

Yes 

No 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  from  the 
inbox? 

■ 

■ 

mm 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

■ 

7.2.3 

On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  usa:  will  see 
on  the  form. 

7.2.4 

Are  the  fields  arranged  in  a  way  that  makes  sense? 

50 


Table  A- 17.  Subtask  7.3:  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

■ 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

■ 

133 

Are  all  the  requests  displayed  on  the  Status  Inquiry  screen 
“touched”  by  the  user  in  some  manner? 

■ 

73.4 

Are  there  any  requests  missing  from  die  Status  hiquiry  screen? 

Hi 

For  each  column  on  the  screen,  is  the  information  for  each  request 
correct? 

■ 

m 

Is  each  column  on  the  screen  returning  the  correct  data  type 
values? 

■ 

m 

7.3.7 

Is  each  column  on  the  screen  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.3.8 

Are  the  contents  of  the  columns  on  the  screen  aligned  properly? 

7.3.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-18.  Subtask  7.4:  Generate  Report 


Task  Number 

Task 

Yes 

No 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  the  Reports  button? 

■ 

m 

7.4.2 

Is  the  information  displayed  in  the  report  easy  to  read? 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

7.4.5 

Is  each  column  in  the  report  returning  the  correct  data  type 
values? 

■ 

■ 

7.4.6 

Is  each  column  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.4.7 

Are  the  contents  of  the  colunms  in  the  report  aligned  properly? 

Task  8.0:  ExitBuylt 


Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  imauthorized  person  fix)m  gaining  access  to  the  system. 


51 


This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  Table  A- 19  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-19.  Task  8.0:  Exit  Buylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

■ 

Budget  Analyst  Role 

Task  List  for  Testing  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  paforms  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  the  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 

Task  0.1:  L(^  Onto  Buylt 

Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  Table  A-20  assists  the  user  m  determining  if  this  task  was  accomplished 
successfully. 
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Table  A-20.  Task  2.0:  Approve  Funds 


Task  Number 

Task 

Yes 

No 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■: 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

0.1.3 

Does  Lotus  Notes  only  allow  die  user  to  enter  a  correct  password? 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

0.1.7 

Does  the  “About  This  Database”  appear  when  the  user 
logs  onto  Buylt  for  the  first  time? 

■ 

■ 

0.1.8 

Can  the  user  display  the  Buylt  startup  screen? 

This  major  process  interfaces  to  the  SOMARDS  legacy  system  and  is  transparent  to  the  user. 
A  “Build  Block”  process  is  executed  at  the  start  of  the  day  and  creates  the  transaction  block  used 
by  Buylt  for  that  day.  As  certifiable  purchase  requests  are  created  during  the  course  of  the  day, 
the  “Certify  Funds”  process  queries  SOMARDS  and  returns  a  message  to  either  certify  or  reject 
the  request  At  the  end  of  the  day,  the  “Reconcile”  process  block  is  executed  to  balance  the 
transaction  block. 


This  task  is  successfully  completed  when  the  Accounting  Classification  field  is  completed  if 
there  is  sufficiait  funds  or  when  a  rejection  explanation  is  provided  for  insufficient  funds  or  for 
an  incorrect  Job  No.  Tables  A-21  through  A-25  assist  the  user  in  determining  if  this  task  was 
accomplished  successfully. 
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Table  A-21.  Subtask  2.1:  Approve  Fund  Source 


Task  Number 

Task 

Yes 

No 

2.1.1 

Does  the  Job  No  field  on  the  purchase  request  contain  the  correct 
information  that  corresponds  to  the  Job  No  assigned  to  the 
requester’s  organization? 

2.1.2 

Is  the  EOR  correct  and  correspond  to  the  items  requested  for 
purchase? 

■ 

Table  A-22.  Subtask  2.2:  Approve  Actual  Cost 


Task  Number 

Task 

Yes 

No  1 

2.2.1 

Does  the  Total  Estimated  Cost  field  contain  the  correct  amount? 

1 

Table  A-23.  Subtask  23:  Certify  Funds 


Task  Number 

Task 

Yes 

No  1 

2.3.1 

Does  SOMARDS  contain  sufficient  funds  in  the  Job  No  account 
to  cover  the  amount  contained  in  die  Total  Estimated  Cost  field? 

■ 

■ 

2.3.2 

ff  there  are  sufficient  funds,  is  the  purchase  request  certified  by 
displa3dng  the  correct  Accounting  Classification  number? 

■ 

■ 

2.3.3 

If  there  are  insufficient  funds,  is  the  purchase  request  rejected  by 
leaving  the  Accounting  Classification  field  blank  and  by 
providing  an  explanation  for  the  rejection? 

■ 

1 

Table  A-24.  Subtask2.4:  Build  Block 


Task  Number 

Task 

Yes 

No 

2.4.1 

Is  a  correctly  formatted  transaction  block  buUt  each  day? 

Table  A-25.  Subtask  23:  Reconcile 


Task  Number 

Task 

Yes 

No 

2.5.1 

Is  the  transaction  block  correctly  reconciled  at  the  end  of  each 
day? 

■ 

■ 
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Task  3.0:  Obtain  Approvals 


For  each  assigned  role,  a  list  of  purchase  requests  is  displayed  on  the  Buylt  startup  screen 
awaiting  approval.  By  clicking  on  the  Pending  button,  the  user  refreshes  the  startup  screen  to 
display  any  requests  that  require  his/her  action.  The  user  then  selects  a  request  for  approval.  The 
user,  as  a  supervisor  or  other  approving  official,  may: 

•  open  a  selected  request. 

•  review  the  request. 

•  close  the  request  and  save  the  approval  for  later. 

•  attach  his/her  approval  to  the  request. 

•  deny  approval  and  enter  an  explanation. 

Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment.  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  the  request 

This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  The  following  checklist  of  subtasks  in 
Table  A-26  will  assist  the  user  in  determining  if  this  task  was  accomplished  successfully. 

Task  7.0:  Submit  Inquiries 

Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
length  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document  Also,  the 
user  cannot  edit  any  information  on  these  requests. 
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Table  A-26.  Subtask  3.1:  Approve  Special  Items 


Task  Number 

Task 

Yes 

No 

3.1.1 

Is  the  information  for  each  purchase  request  on  the  Buylt  startup 
screen  easy  to  read? 

■ 

3.1.2 

Are  all  the  requests  displayed  on  the  startup  screen  awaiting 
approval  from  the  user’s  assigned  role? 

■ 

3.1.3 

Are  there  any  requests  missing  from  the  startup  screen? 

■I 

3.1.4 

For  each  column  on  the  startup  screen,  is  the  information  for  each 
request  correct? 

3.1.5 

Is  each  column  on  the  startup  screen  returning  the  correct  data 
type  values? 

3.1.6 

Is  each  column  on  the  startup  screen  displaying  aU  the 
information  that  is  contained  in  it? 

■ 

3.1.7 

Are  the  contents  of  the  columns  on  the  startup  screen  aligned 
properly? 

■ 

3.1.8 

Are  the  purchase  requests  in  the  right  order? 

3.1.9 

On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

■ 

1 

3.1.10 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  facilitates 
movement  through  the  form? 

■ 

■ 

3.1.11 

If  in  a  supervisor  role,  can  aU  fields  be  edited  correctly? 

N/A 

N/A 

3.1.12 

After  the  supervisor  approves  the  request,  is  a  correct  Document 
reference  Number  automatically  generated? 

■ 

3.1.13 

ff  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be 
edited  correctly? 

■ 

■ 

3.1.14 

If  in  a  contracting  officer  role,  can  only  the  buyer  assignment  be 
entered  correctly? 

N/A 

N/A 

3.1.15 

Can  the  user  close  the  request  and  save  its  approval  for  some  later 
time? 

■ 

3.1.16 

Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

3.1.17 

Can  the  user  approve  the  request? 

3.1.18 

If  the  request  is  denied,  is  it  routed  back  to  the  requester? 

■■ 

3.1.19 

If  the  request  is  approved,  is  it  routed  to  the  next  assigned 
approver? 

■ 
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Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  described  previously,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 


This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  from  the 
Reports  screen  successfully.  Tables  A-27  through  A-30  assist  the  user  in  determining  if  this  task 
was  accomplished  successfully. 


Table  A-27.  Subtask  7.1:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/hibox  User  screen  displayed  after  the  user  clicks  on 
the  Pending  button? 

■ 

7.1.2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

7.1.3 

Are  all  the  requests  displayed  in  the  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

7.1.6 

Is  each  column  in  the  inbox  returning  the  correct  data  type 
values? 

7.1.7 

Is  each  column  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

7.1.8 

Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Task  8.0:  ExitBuylt 


Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  unauthorized  person  from  gaining  access  to  the  system. 
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Table  A-28.  Subtask  7^:  Show  Report  Request 


Task  Number 

Task 

Yes 

No 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  from  the 
inbox? 

■ 

■ 

mm 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

■ 

■ 

1.23 

On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  wiU  see 
on  the  form. 

7.2.4 

Are  the  fields  arranged  in  a  way  that  makes  sense? 

Table  A-29.  Subtask  7  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

HI 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

Hi 

Are  all  the  requests  displayed  on  the  Status  Inquiry  screen 
“touched”  by  the  user  in  some  maimer? 

Are  there  any  requests  missing  from  the  Status  hiquiry  screen? 

For  each  column  on  the  screen,  is  the  information  for  each  request 
correct? 

■ 

mm 

Is  each  column  on  the  screen  returning  the  correct  data  type 
values? 

Is  each  column  on  the  screen  displaying  aU  of  the  information  that 
is  contained  in  it? 

7.3.8 

Are  the  contents  of  the  columns  on  the  screen  aligned  properly? 

7.3.9 

Are  the  purchase  requests  in  the  right  order? 

This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  Table  A-31  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 
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Table  A-30.  Subtask  7.4:  Generate  Report 


Task  Number 

Task 

Yes 

No 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  the  Reports  button? 

■ 

7.4.2 

Is  the  information  displayed  in  the  report  easy  to  read? 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

■■ 

Is  each  column  in  the  report  returning  the  correct  data  type 
values? 

■ 

■ 

Is  each  column  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

lA.l 

Are  the  contents  of  the  columns  in  the  report  aligned  properly? 

Table  A-31.  Subtask  8.0:  ExitBuylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

■ 

Contracting  Officer  and  Buyer  Role 


Task  List  for  Testii^  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  performs  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  the  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 
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Task  0.1:  Log  Onto  Buylt 


Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  Table  A-32  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-32.  Task  3.0:  Obtain  Approvals 


Task  Number 

Task 

Yes 

No 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■ 

■ 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

0.1.3 

Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct  password? 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

0.1.7 

Does  the  “About  This  Database”  appear  when  die  user 
logs  onto  Buylt  for  the  first  time? 

■ 

■ 

0.1.8 

Can  the  user  display  the  Buylt  startup  screen? 

=j 

For  each  assigned  role,  a  list  of  purchase  requests  is  displayed  on  the  Buylt  startup  screen 
awaiting  approval.  By  clicking  on  the  Pending  button,  the  user  refreshes  the  startup  screen  to 
display  any  requests  that  require  his/her  action.  The  user  then  selects  a  request  for  approval.  The 
user,  as  a  supervisor  or  other  approving  official  may: 


*  open  a  selected  request. 

•  review  the  request. 

♦  close  the  request  and  save  the  approval  for  later. 

•  attach  his/her  approval  to  the  request. 

♦  deny  approval  and  enter  an  explanation. 
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Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment.  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  the  request 

This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  Table  A-33  assists  the  user  in  determining  if 
this  task  was  accomplished  successfully. 

Task  5.0;  Prepare  Purchase  Order 

This  major  process  interfaces  to  the  SAACONS  legacy  system  and  is  transparent  to  the  user. 
The  &st  step  of  the  process  is  for  the  contracting  officer  to  assign  a  buyer.  This  triggers  the 
upload  of  the  purchase  request  information  to  SAACONS.  The  buyer  then  proceeds  to  work 
within  SAACONS.  The  second  part  of  the  SAACONS  interface  is  the  download  of  information 
(actual  costs,  selected  vendor,  delivery  date,  etc.).  The  request  is  forwarded  to  receiving  in  order 
to  alert  them  of  the  pending  shipment. 

This  task  is  successfully  completed  when  the  SAACONS  information  appears  on  the 
purchase  request  and  when  receiving  is  notified  of  the  pending  shipment.  Tables  A-34  through 
A-37  assist  the  user  in  determining  if  this  task  was  accomplished  successfully. 
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Table  A-33.  Subtask  3.1:  Approve  Special  Items 


Task  Number 

Task 

Yes 

No 

3.1.1 

Is  the  information  for  each  purchase  request  on  the  Buylt  startup 
screen  easy  to  read? 

3.1.2 

Are  all  the  requests  displayed  on  the  startup  screen  awaiting 
approval  from  the  user’s  assigned  role? 

3.1.3 

Are  there  any  requests  missing  from  the  startup  screen? 

■1 

3.1.4 

For  each  column  on  the  startup  screen,  is  the  information  for  each 
request  correct? 

3.1.5 

Is  each  column  on  the  startup  screen  returning  the  correct  data 
type  values? 

3.1.6 

Is  each  column  on  the  startup  screen  displaying  all  the 
information  that  is  contained  in  it? 

3.1.7 

Are  the  contents  of  the  columns  on  the  startup  screen  aligned 
properly? 

3.1.8 

Are  the  purchase  requests  in  the  right  order? 

■I 

3.1.9 

On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

1 

1 

3.1.10 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  that 
facilitates  movement  through  the  form? 

■ 

3.1.11 

If  in  a  supervisor  role,  can  all  fields  be  edited  correctly? 

N/A 

ml 

3.1.12 

After  the  supervisor  approves  die  request,  is  a  correct  Document 
Reference  Number  automatically  generated? 

■ 

3.1.13 

If  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be 
edited  correctly? 

N/A 

N/A 

3.1.14 

If  in  a  contracting  officer  role,  can  only  the  buyer  assignment  be 
entered  correctly? 

■ 

■ 

3.1.15 

Can  the  user  close  the  request  and  save  its  approval  for  some  later 
time? 

■ 

3.1.16 

Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

3.1.17 

Can  the  user  approve  the  request? 

3.1.18 

If  the  request  is  denied,  is  it  routed  back  to  the  requester? 

3.1.19 

If  the  request  is  approved,  is  it  routed  to  the  next  assigned 
approver? 

■ 

62 


Table  A-34.  SubtaskS.l:  Assign  the  Buyer 


Task  Number 

Task 

Yes 

No  1 

5.1.1 

Has  the  contracting  officer  assigned  a  buyer  for  die  purchase 
request? 

■ 

5.1.2 

Does  the  buyer  information  appear  in  the  vendor  information  on 
the  purchase  request? 

■ 

■ 

Table  A-35.  Subtask  5^:  Approve  Purchase 


Task  Number 

Task 

Yes 

No 

5.2.1 

Has  the  selected  buyer  approved  the  purchase  request? 

5.2.2 

Has  the  selected  buyer  created  award  information  in  SAACONS? 

5.2.3 

If  the  buyer  denied  approval,  is  the  rejected  request  returned  to 
the  contracting  officer? 

■ 

Table  A-36.  Subtask  53:  Get  Actual  Costs 


Task  Number 

Task 

Yes 

No  1 

5.3.1 

Was  the  correct  award  information  downloaded  from  SAACONS 
to  the  purchase  request? 

■ 

5.3.2 

Do  the  Actual  Costs  fields  on  the  purchase  request  contain  the 
correct  amounts? 

■ 

Table  A-37.  Subtask  5.4:  Get  Purchase  Order 


Task  Number 

Task 

Yes 

No  1 

5.4.1 

Has  the  completed  purchase  request  been  forwarded  to  receiving 
pending  receipt  of  shipment? 

■ 

■ 
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Task  7.0:  Submit  Inquiries 


Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
length  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document.  Also,  the 
user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  described,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 

This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  from  the 
Reports  screen  successfully.  Tables  A-38  through  A-41  assist  die  user  in  determining  if  this  task 
was  accomplished  successfully. 

Task  8.0:  ExitBuylt 

Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  unauthorized  person  from  gaining  access  to  the  system. 

This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  Table  A-42  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 
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Table  A-38.  Subtask  7.1:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/Inbox  User  screen  displayed  after  the  user  clicks  on 
the  Pending  button? 

l.\2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

1 

■ 

7.1.3 

Are  all  the  requests  displayed  in  the  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

■ 

7.1.6 

Is  each  colunm  in  the  inbox  returning  the  correct  data  type 
values? 

■ 

lA.l 

Is  each  column  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

I 

■ 

7.1.8 

Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-39.  Subtask  7.2:  Show  Report  Request 


Task  Number 

Task 

Yes 

No  1 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  from  the 
inbox? 

■ 

■ 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

■ 

m 

On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

■ 

1 

1  7.2.4 

Are  the  fields  arranged  in  a  way  that  makes  sense? 
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Table  A-40.  Subtask  73:  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

H 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

Hi 

Are  all  the  requests  displayed  on  the  Status  hiquiry  screen 
“touched”  by  the  user  in  some  manner? 

Are  there  any  requests  missing  from  the  Status  Inquiry  screen? 

■■ 

■■ 

For  each  column  on  the  screen,  is  the  information  for  each  request 
correct? 

■ 

Is  each  column  on  the  screen  returning  the  correct  data  type 
values? 

7.3.7 

Is  each  column  on  the  screen  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.3.8 

Are  the  contents  of  the  columns  on  the  screen  aligned  properly? 

7.3.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-41.  Subtask  7.4:  Generate  Report 


Task  Number 

Task 

Yes 

No 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  the  Reports  button? 

■ 

■ 

7.4.2 

Is  the  information  displayed  in  tiie  report  easy  to  read? 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

■i 

7.4.5 

Is  each  colunm  in  the  report  returning  the  correct  data  type 
values? 

■ 

7.4.6 

Is  each  colunm  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.4.7 

Are  the  contents  of  the  colunms  in  the  report  aligned  properly? 

Table  A-42.  Task  8.0:  ExitBuylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

■ 
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Property  Book  Officer  Role 


Task  List  for  Testing  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  performs  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  the  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 

Task  0.1:  Log  Onto  Buylt 

Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  to  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  Table  A-43  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 

For  each  assigned  role,  a  list  of  purchase  requests  is  displayed  on  the  Buylt  startup  screen 
awaiting  approval.  By  clicking  on  the  Pending  button,  the  user  refreshes  the  startup  screen  to 
display  any  requests  that  require  his/her  action.  The  user  then  selects  a  request  for  approval.  The 
user,  as  a  supervisor  or  other  approving  official,  may: 
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Table  A-43.  Task  3.0;  Obtain  Approvals 


Task  Number 

Task 

Yes 

No 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■ 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

0.1.3 

Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct  password? 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

■■ 

0.1.7 

Does  the  “About  This  Database”  appear  when  the  user 
logs  onto  Buylt  for  the  first  time? 

■ 

0.1.8 

Can  the  user  display  the  Buylt  startup  screen? 

•  open  a  selected  request. 

•  review  the  request. 

•  close  the  request  and  save  the  approval  for  later. 

•  attach  his/her  approval  to  the  request. 

•  deny  approval  and  enter  an  explanation. 

Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment.  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  the  request. 

This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  Tables  A-44  and  A-45  assist  the  user  in 
determining  if  this  task  was  accomplished  successfully. 
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Table  A-44.  Subtask  3.1:  Approve  Special  Items 


Task  Number 

Task 

Yes 

No 

3.1.1 

Is  the  information  for  each  purchase  request  on  the  Buylt  startup 
screen  easy  to  read? 

■ 

■ 

3.1.2 

Are  all  the  requests  displayed  on  the  startup  screen  awaiting 
approval  from  the  user’s  assigned  role? 

■ 

■ 

3.1.3 

Are  there  any  requests  missing  from  the  startup  screen? 

_ 

3.1.4 

For  each  column  on  the  startup  screen,  is  the  information  for  each 
request  correct? 

■ 

■ 

3.1.5 

Is  each  column  on  the  startup  screen  returning  the  correct  data 
type  values? 

1 

■ 

3.1.6 

Is  each  column  on  the  startup  screen  displaying  all  the 
information  that  is  contained  in  it? 

3.1.7 

Are  the  contents  of  the  columns  on  the  startup  screen  aligned 
properly? 

■ 

■ 

3.1.8 

Are  the  purchase  requests  in  the  right  order? 

3.1.9 

On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

3.1.10 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  that 
facilitates  movement  through  the  form? 

■ 

■ 

3.1.11 

If  in  a  supervisor  role,  can  all  fields  be  edited  correctly? 

N/A 

N/A 

3.1.12 

After  the  supervisor  approves  the  request,  is  a  correct  Document 
Reference  Number  automatically  generated? 

3.1.13 

If  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be 
edited  correctly? 

N/A 

N/A 

3.1.14 

If  in  a  contracting  officer  role,  can  only  the  buyer  assignment  be 
entered  correctly? 

N/A 

N/A 

3.1.15 

Can  the  user  close  the  request  and  save  its  approval  for  some  later 
time? 

H 

■ 

3.1.16 

Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

3.1.17 

Can  the  user  approve  the  request? 

3.1.18 

If  the  request  is  denied,  is  it  routed  back  to  the  requester? 

3.1.19 

If  the  request  is  approved,  is  it  routed  to  the  next  assigned 
approver? 

■ 

■ 
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Table  A-45.  Subtask  3.2:  Attach  Item  Tag 


Task  Number 

Task 

Yes 

No 

3.2.1 

In  a  property  book  officer  role,  can  only  item  tags  be  entered 
correctly  and  no  other  fields  be  edited? 

Task  7.0:  Submit  Inquiries 

Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
length  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document.  Also,  the 
user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  diis  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  described,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 

This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  from  the 
Reports  screen  successfully.  Tables  A-46  through  A-49  assist  the  user  in  determining  if  this  task 
was  accomplished  successfully. 

Task  8.0:  ExitBuylt 

Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  unauthorized  person  from  gaining  access  to  the  system. 
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Table  A-46.  Subtask  7.1:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/Inbox  User  screen  displayed  after  the  user  clicks  on 
the  Pending  button? 

1 

l.\2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

■ 

7.1.3 

Are  all  the  requests  displayed  in  die  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

■ 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

7.1.6 

Is  each  column  in  the  inbox  returning  the  correct  data  type 
values? 

7.1.7 

Is  each  colunm  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

1 

7.1.8 

Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-47.  Subtask  7.2:  Show  Report  Request 


Task  Number 

Task 

Yes 

No 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  fixim  the 
inbox? 

■ 

■ 

mm 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

■ 

m 

On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactiy  match  the  field  names  that  the  user  will  see 
on  the  form. 

1 

1 

llA 

Are  the  fields  arranged  in  a  way  that  makes  sense? 
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Table  A-48.  Subtask  7  J:  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  hiquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

mm 

Are  all  the  requests  displayed  on  the  Status  Inquiry  screen 
“touched”  by  the  user  in  some  manner? 

■ 

Are  there  any  requests  missing  firom  the  Status  Inquiry  screen? 

For  each  column  on  the  screen,  is  the  information  for  each  request 
correct? 

Is  each  column  on  the  screen  returning  the  correct  data  type 
values? 

1 

Is  each  column  on  the  screen  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.3.8 

Are  the  contents  of  the  columns  on  the  screen  aligned  properly? 

7.3.9 

Are  die  purchase  requests  in  the  right  order? 

Table  A-49.  Subtask  7.4:  Generate  Report 


Task  Number 

Task 

Yes 

No  1 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  the  Reports  button? 

■ 

7.4.2 

Is  the  information  displayed  in  the  report  easy  to  read? 

_ 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

_ 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

1^1 

7.4.5 

Is  each  column  in  the  report  returning  the  correct  data  type 
values? 

■ 

7.4.6 

Is  each  column  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

7.4.7 

Are  the  contents  of  the  columns  in  the  report  aligned  properly? 
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This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  Table  A-50  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-50.  Task  8.0:  Exit  Buylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

Receiving  Role 

Task  List  for  Testii^  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  performs  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  other  approverfs),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  the  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 

Task  0.1:  Log  Onto  Buylt 

Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  to  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  onto  Buylt  and  display  the  Buylt 
startup  screen.  Table  A-51  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 
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Table  A-51.  Task  3.0:  Obtain  Approvals 


Task  Number 

Task 

Yes 

No 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■ 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

0.1.3 

Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct  password? 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

0.1.7 

Does  the  “About  This  Database”  appear  when  the  user 
logs  onto  Buylt  for  the  first  time? 

0.1.8 

Can  the  user  display  the  Buylt  startup  screen? 

For  each  assigned  role,  a  list  of  purchase  requests  is  displayed  on  the  Buylt  startup  screen 
awaiting  approval.  By  clicking  on  the  Pending  button,  the  user  refreshes  the  startup  screen  to 
display  any  requests  that  require  his/her  action.  The  user  then  selects  a  request  for  approval.  The 
user,  as  a  supervisor  or  other  approving  official,  may: 


•  open  a  selected  request. 

•  review  the  request. 

•  close  the  request  and  save  the  approval  for  later. 

•  attach  his/her  approval  to  the  request. 

•  deny  approval  and  enter  an  explanation. 

Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment.  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  the  request. 

This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  Tables  A-52  and  A-53  assist  the  user  in 
determining  if  this  task  was  accomplished  successfully. 
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Table  A-52.  Subtask  3.1:  Approve  Special  Items 


Task  Number 

Task 

Yes 

No 

3.1.1 

Is  the  information  for  each  purchase  request  on  the  Buylt  startup 
screen  easy  to  read? 

3.1.2 

Are  all  the  requests  displayed  on  the  startup  screen  awaiting 
approval  from  the  user’s  assigned  role? 

■ 

■ 

3.1.3 

Are  there  any  requests  missing  from  the  startup  screen? 

3.1.4 

For  each  column  on  the  startup  screen,  is  the  information  for  each 
request  correct? 

■ 

■ 

3.1.5 

Is  each  column  on  the  startup  screen  returning  the  correct  data 
type  values? 

■ 

3.1.6 

Is  each  column  on  the  startup  screen  displaying  all  the 
information  that  is  contained  in  it? 

■ 

■ 

3.1.7 

Are  the  contents  of  the  columns  on  the  startup  screen  aligned 
properly? 

■ 

■ 

3.1.8 

Are  the  purchase  requests  in  the  right  order? 

IHI 

3.1.9 

On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

1 

1 

3.1.10 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  that 
facilitates  movement  through  the  form? 

■ 

■ 

3.1.11 

If  in  a  supervisor  role,  can  all  fields  be  edited  correctly? 

N/A 

N^ 

3.1.12 

After  the  supervisor  approves  the  request,  is  a  correct  Document 
Reference  Number  automatically  generated? 

1 

■ 

3.1.13 

If  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be 
edited  correctly? 

N/A 

N/A 

3.1.14 

If  in  a  contracting  officer  role,  can  only  the  buyer  assigmnent  be 
entered  correctly? 

N/A 

N/A 

3.1.15 

Can  the  user  close  the  request  and  save  its  approval  for  some  later 
time? 

■ 

3.1.16 

Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

3.1.17 

Can  the  user  approve  the  request? 

3.1.18 

If  die  request  is  denied,  is  it  routed  back  to  the  requester? 

3.1.19 

If  the  request  is  approved,  is  it  routed  to  the  next  assigned 
approver? 

■ 

■ 
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Table  A-53.  Subtask  33:  Property  Approval 


Task  Number 

Task 

Yes 

No 

3.3.1 

In  a  receiving  role,  can  only  tag  items  be  edited  correctly? 

Task  6.0:  Receive  Shipment 

Sometime  after  the  completed  purchase  request  is  forwarded  to  receiving,  the  shipment  is 
delivered  to  the  warehouse.  Receiving  marks  the  request  as  “received”  and  checks  off  any  tagged 
items  once  they  are  properly  accounted.  At  this  point,  Buylt  notifies  the  requester  of  receipt  and 
allows  the  user  to  accept  or  return  items  after  they  are  delivered. 

This  task  is  successfully  completed  when  receiving  marks  the  request  as  received  and  checks 
off  any  tagged  items,  and  when  Buylt  notifies  the  user  of  receipt  and  allows  the  user  to  either 
accept  or  return  the  items.  After  the  user  accepts  or  returns  the  items,  Buylt  marks  the  purchase 
request  as  closed.  Tables  A-54  through  A-56  assist  the  user  in  determining  if  this  task  was 
accomplished  successfully. 


Table  A-54.  Subtask  6.1:  Receive  Order 


Task  Number 

Task 

Yes 

No 

6.1.1 

Has  receiving  marked  the  request  as  correctly  received? 

Table  A-55.  Subtask  6.2:  Tag  Received  Items 


Task  Number 

Task 

Yes 

No 

6.2.1 

Has  receiving  properly  accounted  for  all  tagged  items  and 
correctly  checked  them  off? 

■ 

■ 
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Table  A-56.  Subtask  63:  Accept  Shipment 


Task  Number 

Task 

Yes 

No 

6.3.1 

Has  Buylt  notified  the  requester  of  receipt  of  the  purchase 
request? 

■ 

■ 

6.3.2 

Does  Buylt  allow  the  user  to  accept  items? 

_ 

6.3.3 

Does  Buylt  allow  the  user  to  return  items? 

6.3.4 

After  the  user  accepts  or  returns  items,  does  Buylt  mark  the 
purchase  request  as  closed  and  remove  it  from  the  active  system? 

■ 

■ 

Task  7.0:  Submit  Inquiries 

Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
length  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document.  Also,  the 
user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  described,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 

This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  hiquity  screen  and  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  from  the 
Reports  screen  successfully.  Tables  A-57  through  A-60  assist  the  user  in  determining  if  this  task 
was  accomplished  successfully. 
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Table  A-57.  Subtask  7.1:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/lhbox  User  screen  displayed  after  the  user  clicks  on 
the  Pending  button? 

1 

l.\2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

■ 

7.1.3 

Are  all  the  requests  displayed  in  the  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

■■ 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

■ 

7.1.6 

Is  each  column  in  the  inbox  returning  the  correct  data  type 
values? 

■ 

lA.l 

Is  each  colunm  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

7.1.8 

Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-58.  Subtask  7.2:  Show  Report  Request 


Task  Number 

Task 

Yes 

No 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  from  the 
inbox? 

■ 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

m 

On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

Are  the  fields  arranged  in  a  way  that  makes  sense? 
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Table  A“59.  Subtask  73:  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

■ 

■ 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

■ 

■ 

Are  all  the  requests  displayed  on  the  Status  Inquiry  screen 
“touched”  by  the  user  in  some  manner? 

■ 

Are  there  any  requests  missing  from  the  Status  Inquiry  screen? 

_ 

For  each  column  on  the  screen,  is  the  information  for  each  request 
correct? 

■ 

Is  each  colunm  on  the  screen  returning  the  correct  data  type 
values? 

■ 

■ 

7.3.7 

Is  each  column  on  the  screen  displaying  all  of  the  information  (hat 
is  contained  in  it? 

■ 

7.3.8 

Are  the  contents  of  the  columns  on  the  screen  aligned  properly? 

7.3.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-60.  Subtask  7.4:  Generate  Report 


Task  Number 

Task 

Yes 

No 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  die  Reports  button? 

■ 

7.4.2  ■ 

Is  the  information  displayed  in  the  report  easy  to  read? 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

7.4.5 

Is  each  column  in  the  report  returning  the  correct  data  type 
values? 

■ 

■ 

7.4.6 

Is  each  column  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

7.4.7 

Are  the  contents  of  the  columns  in  the  report  aligned  properly? 
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Task  8.0:  ExitBuylt 


Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  unauthorized  person  from  gaining  access  to  the  system. 

This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s  desktop 
workspace.  Table  A-61  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-61.  Task  8.0:  ExitBuylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

■ 

ADP  Approver 

Task  List  for  Testing  Buylt 

Directions:  The  following  tasks  are  to  be  performed  by  users  to  determine  if  Buylt  is 
working  correctly  and  efficiently.  These  tasks  are  arranged  according  to  a  corresponding  role 
assigned  to  a  user.  The  user  performs  those  tasks  assigned  to  a  role.  The  roles  are  requester, 
supervisor,  budget  analyst,  odier  approver(s),  contracting  officer,  property  book  officer,  buyer,  or 
receiving.  As  each  task  is  executed,  the  user  evaluates  the  results  and  either  verifies  that  the  task 
was  accomplished  successfully  or  reports  the  error  via  the  Buylt  discussion  database.  Testing  is 
successfully  completed  when  the  users  in  their  corresponding  roles  have  correctly  executed  all 
tasks. 
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Task  0.1:  Log  Onto  Buylt 


Logon  is  used  by  all  roles.  The  logon  process  provides  security  by  allowing  only  authorized 
users  access  the  system  via  password  protection. 

This  task  is  completed  successfully  when  the  user  can  log  into  Buylt  and  display  the  Buylt 
startup  screen.  Table  A-62  will  assist  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-62.  Task  3.0:  Obtain  Approvals 


Task  Number 

Task 

Yes 

No  1 

0.1.1 

Does  the  user  have  a  Lotus  Notes  icon  on  his/her  desktop 
workspace? 

■ 

■ 

0.1.2 

Can  the  user  log  onto  Lotus  Notes  using  a  password? 

0.1.3 

Does  Lotus  Notes  only  allow  the  user  to  enter  a  correct  password? 

0.1.4 

Is  there  a  Buylt  icon  on  the  Lotus  Notes  workspace? 

0.1.5 

Can  the  user  log  onto  Buylt  using  a  password? 

0.1.6 

Does  Buylt  only  allow  the  user  to  enter  a  correct  password? 

■1 

0.1.7 

Does  the  “About  This  Database”  appear  when  the  user 
logs  onto  Buylt  for  the  first  time? 

■ 

1 

0.1.8 

Can  the  user  display  the  Buylt  startup  screen? 

=1 

For  each  assigned  role,  a  list  of  purchase  requests  is  displayed  on  the  Buylt  startup  screen 
awaiting  approval.  By  clicking  on  the  Pending  button,  the  user  refreshes  the  startup  screen  to 
display  any  requests  that  require  his/her  action.  The  user  then  selects  a  request  for  approval.  The 
user,  as  a  supervisor  or  other  approving  official,  may: 


•  open  a  selected  request. 

•  review  the  request. 

•  close  the  request  and  save  the  approval  for  later. 

•  attach  his/her  approval  to  the  request 

•  deny  approval  and  enter  an  explanation. 
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Additionally,  the  property  book  officer  attaches  item  tags  to  the  individual  items  in  order  to 
flag  them  during  receipt  of  the  shipment.  The  Document  Reference  Number  is  automatically 
generated  after  the  supervisor  approves  the  request. 

This  task  is  successfully  completed  when  the  user,  as  the  approving  official,  can  successfully 
select  a  purchase  request  assigned  to  his/her  role  for  approval,  review  the  request,  and  attach 
his/her  approval  or  rejection  to  a  purchase  request.  Table  A-63  assists  the  user  in  determining  if 
this  task  was  accomplished  successfully. 

Task  7.0:  Submit  Inquiries 

Clicking  on  the  Status  button  displays  the  Status  Inquiry  screen.  This  screen  lists  the  requests 
that  were  “touched”  by  the  user  either  as  a  requester  or  as  an  approving  official.  Requests  are 
listed  by  Document  Reference  Number  and  show  the  requester,  current  approval  status,  the 
length  of  time  the  request  is  in  the  current  status,  and  the  date  required.  By  selecting  a  specific 
document,  the  user  views  all  purchase  request  information  available  for  that  document.  Also,  the 
user  cannot  edit  any  information  on  these  requests. 

Clicking  on  the  Reports  button  displays  Reports  screen.  From  this  screen,  the  user  can  select 
the  Cycle  Time  Report,  request  the  Status  as  previously  described,  or  go  back  to  the  previous 
menu.  The  Cycle  Time  report  computes  the  average  time  a  selected  request  waits  for  approval  in 
the  various  functional  areas. 

This  task  is  successfully  completed  when  the  user  can  review  a  selected  purchase  request  on 
the  Status  Inquiry  screen  and  obtain  a  Cycle  Time  report  for  a  selected  purchase  request  firom  the 
Reports  screen  successfully.  Tables  A-64  through  A-67  assist  the  user  in  determining  if  this  task 
was  accomplished  successfully. 
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Table  A-63.  Subtask  3.1:  Approve  Special  Items 


Task  Number 

Task 

3.1.1 

Is  the  information  for  each  purchase  request  on  the  Buylt  startup 
screen  easy  to  read? 

3.1.2 

Are  all  the  requests  displayed  on  the  startup  screen  awaiting 
approval  from  the  user’s  assigned  role? 

3.1.3 

Are  there  any  requests  missing  from  the  startup  screen? 

3.1.4 

For  each  column  on  the  startup  screen,  is  the  information  for  each 
request  correct? 

3.1.5 

Is  each  column  on  the  startup  screen  returning  the  correct  data 
type  values? 

3.1.6 

Is  each  column  on  the  startup  screen  displaying  all  the 
information  that  is  contained  in  it? 

3.1.7 

Are  the  contents  of  the  colunms  on  the  startup  screen  aligned 
properly? 

3.1.8 

Are  the  purchase  requests  in  the  right  order? 

3.1.9 

On  the  Approval  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

3.1.10 

Are  the  fields  arranged  in  a  way  that  makes  sense  and  that 
facilitates  movement  through  the  form? 

3.1.11 

If  in  a  supervisor  role,  can  all  fields  be  edited  correctly? 

3.1.12 

After  the  supervisor  approves  the  request,  is  a  correct  Document 
Reference  Number  automatically  generated? 

3.1.13 

If  in  a  budget  analyst  role,  can  only  the  fund  source  fields  be 
edited  correctly? 

3.1.14 

If  in  a  contracting  officer  role,  can  only  the  buyer  assignment  be 
entered  correctly? 

3.1.15 

Can  the  user  close  the  request  and  save  its  approval  for  some  later 
time? 

3.1.16 

Can  the  user  deny  approval  and  enter  an  explanation  for  denial? 

3.1.17 

Can  the  user  approve  the  request? 

3.1.18 

If  the  request  is  denied,  is  it  routed  back  to  the  requester? 

3.1.19 

If  the  request  is  approved,  is  it  routed  to  the  next  assigned 
approver? 

N/A  N/A 


N/A  N/A 


N/A  N/A 


Table  A-64.  Subtask  7.1:  Show  Inbox 


Task  Number 

Task 

Yes 

No 

7.1.1 

Is  the  Startup/Inbox  User  screen  displayed  after  the  user  clicks  oh 
the  Pending  button? 

7.1.2 

Is  the  information  for  each  purchase  request  displayed  in  the 
inbox  easy  to  read? 

7.1.3 

Are  all  the  requests  displayed  in  the  inbox  awaiting  approval  from 
the  user’s  assigned  role? 

7.1.4 

Are  there  any  requests  missing  from  the  inbox? 

7.1.5 

For  each  column  in  the  inbox,  is  the  information  for  each  request 
correct? 

7.1.6 

Is  each  column  in  the  inbox  returning  the  correct  data  type 
values? 

7.1.7 

Is  each  column  in  the  inbox  displaying  all  of  the  information  that 
is  contained  in  it? 

7.1.8 

Are  the  contents  of  the  columns  in  the  inbox  aligned  properly? 

7.1.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-65.  Subtask  7.2:  Show  Report  Request 


Task  Number 

Task 

Yes 

No 

7.2.1 

Can  the  user  select  and  display  any  purchase  request  from  the 
inbox? 

■ 

mm 

Can  the  user  only  view  and  not  edit  the  displayed  purchase 
request? 

■ 

7.2.3 

On  the  Inquiry  screen,  are  the  fields  clearly  labeled  and  easy  to 
understand?  Please  note  that  the  field  names  used  in  this  testing 
plan  may  not  exactly  match  the  field  names  that  the  user  will  see 
on  the  form. 

1 

1 

7.2.4 

Are  the  fields  arranged  in  a  way  that  makes  sense? 

_ ! 

LJ 
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Table  A-66.  Subtask  73:  Show  Status 


Task  Number 

Task 

Yes 

No 

7.3.1 

Is  the  Status  Inquiry  screen  displayed  after  the  user  clicks  on  the 
Status  button? 

■ 

Is  the  information  for  each  purchase  request  displayed  on  the 

Status  Inquiry  screen  easy  to  read? 

1 

■ 

Are  all  the  requests  displayed  on  the  Status  Inquiry  screen 
“touched”  by  the  user  in  some  manner? 

■ 

Are  there  any  requests  missing  from  the  Status  Inquiry  screen? 

_ 

For  each  column  on  the  screen,  is  the  information  for  each  request 
correct? 

■ 

73.6 

Is  each  colunm  on  the  screen  returning  the  correct  data  type 
values? 

■ 

7.3.7 

Is  each  colunm  on  the  screen  displa5dng  all  of  the  information  that 
is  contained  in  it? 

1 

■ 

7.3.8 

Are  the  contents  of  the  colunms  on  the  screen  aligned  properly? 

7.3.9 

Are  the  purchase  requests  in  the  right  order? 

Table  A-67.  Subtask  74:  Generate  Report 


Task  Number 

Task 

Yes 

No  1 

7.4.1 

Is  the  Cycle  Time  Report  displayed  after  the  user  selects  a 
purchase  request  and  clicks  on  die  Reports  button? 

■ 

7.4.2 

Is  the  information  displayed  in  the  report  easy  to  read? 

7.4.3 

Is  the  information  in  the  report  in  the  correct  order? 

7.4.4 

For  each  column  in  the  report,  is  the  information  correct? 

7.4.5 

Is  each  column  in  the  report  returning  the  correct  data  type 
values? 

■ 

■ 

7.4.6 

Is  each  column  in  the  report  displaying  all  of  the  information  that 
is  contained  in  it? 

■ 

■ 

7.4.7 

Are  the  contents  of  the  columns  in  the  report  aligned  properly? 

UJ 
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Task  8.0:  ExitBuylt 


Exiting  Buylt  is  used  by  all  roles.  The  exit  process  ensures  the  system  is  properly  closed  and 
prevents  any  unauthorized  person  from  gaining  access  to  the  system. 

This  task  is  completed  successfully  when  the  user  can  exit  Buylt  and  return  to  the  PC’s 
desktop  workspace.  Table  A-68  assists  the  user  in  determining  if  this  task  was  accomplished 
successfully. 


Table  A-68.  Task  8.0:  ExitBuylt 


Task  Number 

Task 

Yes 

No 

8.0.1 

By  clicking  on  the  “X”  in  the  upper  right-hand  comer  of  the 
screen,  does  the  user  return  to  the  PC’s  desktop  workspace? 

■ 

■ 
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Glossary 


black  box  testing  - 

a  testing  methodology  that  attempts  to  derive  sets  of  inputs  that  will  fully 
exercise  all  of  the  functional  requirements  of  a  system. 

formulas  - 

macros  created  using  Notes  formula  language  that  consist  of  ©functions 
and  ©Commands;  can  be  used  in  Smarticons,  replication  formulas,  agents, 
forms,  fields,  views,  buttons,  hotspots,  actions,  and  navigators. 

hotspots  - 

graphics,  text,  or  buttons  in  a  form,  document,  or  Navigator  that  when 
double-clicked  carry  out  a  task  or  specific  action. 

LotusScript  - 

a  Visual  Basic-like  programming  language  that  allows  developers  to  write 
scripts  for  accessing  and  manipulating  Notes  objects  and  interface;  it 
includes  a  browser  and  debugger. 

pilot - 

group  of  users  representing  the  appropriate  mix  of  functional  areas  who  test 
the  usability,  effectiveness,  and  efficiency  of  a  system  and  who  recommend 
changes  for  improvements. 

repository  - 

a  database  that  acts  as  the  center  for  both  accumulation  and  storage  of 
software  engineering  information  such  as  system  versions. 

SAACONS - 

Standard  Army  Automated  Contracting  System  residing  on  an  HP  9000 
using  a  Progress  database  management  system.  This  system  provides  a 
mechanism  to  update,  maintain,  and  monitor  all  U.S.  Army  Research 
Laboratory  small-purchase  contracts.  The  functional  proponent  is  the 
Procurement  Office. 

SOMARDS- 

Standard  Operations  and  Maintenance  Army  Research  and  Development 
System  residing  at  the  megacenter  in  Rock  Island,  IL.  This  system  is  an 
automated  finance  and  accounting  system  that  provides  fund  control  using  a 
System-2000  database  management  system.  The  functional  proponent  is 
the  Defense  Finance  and  Accounting  Service. 

template  - 

A  Lotus  Notes  database  design  that  can  be  used  as  a  starting  point  for  a  new 
database. 

white  box  testing  - 

a  test-case  design  method  that  uses  the  control  structure  of  the  procedural 
design  to  derive  test  cases. 
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